Für ein Heimautomatisierungsprojekt habe ich eine API erstellt (geschrieben in ASP.NET, also gehostet in IIS) und meine eigene Android-App geschrieben, um mit dieser API zu kommunizieren. Um zu verhindern, dass Leute auf bestimmte Endpunkte in dieser API zugreifen, möchte ich die Endpunkte schützen, die nicht öffentlich sein sollen. Einige bleiben für mein Statistik-Dashboard öffentlich.
Ich habe ein Client-PKI-Zertifikat für die App, das ich von einer offiziellen und staatlich anerkannten Organisation erworben habe und das eine OCSP-Responder-URL enthält. Wenn die App auf die geschützten Endpunkte zugreift, ist dieses Zertifikat enthalten. Der letzte Schritt wäre nun, dass der Server die Gültigkeit dieses Zertifikats bei eingehenden Anfragen überprüft. Dabei sind mir folgende mögliche Szenarien eingefallen:
- Zertifikat ist gültig
- Die CA-Hierarchie des Zertifikats ist ungültig (ich bin Programmierer, also entschuldige ich, wenn ich diesen Satz verunstaltet habe)
- Das Zertifikat ist abgelaufen (ich nehme an, der OCSP-Responder wird das zurückgeben)
- Kein Zertifikat enthalten
Kann IIS dieses Problem lösen? Ich habe eigentlich nur OCSP-Stapling gefunden, das nichts mit dem Client-Zertifikat zu tun hat. Grundsätzlich sollte der TLS-Handshake abgebrochen werden, damit die API nicht einmal erreicht werden kann.
Ich verwende HAProxy, um die Anfragen an den richtigen Server in meinem Netzwerk weiterzuleiten. Wenn IIS also nicht möglich ist, könnte HAProxy das dann tun?
Danke!
Antwort1
IIS kann Client-Zertifikate mit OCSP validieren. HAProxy kann das meines Wissens nicht. Am besten ist es, das Client-Zertifikat an das IIS-Backend weiterzuleiten.
Beachten Sie, dass Sie OCSP oder Certificate Revocation List (CRL) nur verwenden, um den Widerrufsstatus eines Zertifikats zu überprüfen – sonst nichts.
Daher besteht die Validierung eines Zertifikats weiterhin aus der Überprüfung der Kette vom Zertifikat bis zu einem Vertrauensanker, der Überprüfung, ob das Zertifikat nicht abgelaufen ist und der Überprüfung, ob das Zertifikat die richtige Schlüsselverwendung verwendet; unabhängig davon, ob OCSP (oder CRLs) verwendet werden.