Auswirkungen des Ausfalls des Onlineresponders (OCSP) auf die Überprüfung des Sperrstatus eines Zertifikats

Nachfolgend wird untersucht, wie sich die Überprüfung des Sperrstatus verhält, wenn der Onlineresponder ausfallen sollte. Je nach Konfiguration der ausgestellten Zertifikate kann es hier zu stark abweichendem Verhalten kommen.

Der Online Responder (Online Certificate Status Protocol, OCSP) ist eine alternative Möglichkeit, Sperrstatusinformationen für Zertifikate bereitzustellen. Entitäten, die den Sperrstatus eines Zertifikats überprüfen möchten, müssen dank OCSP nicht die komplette Liste aller widerrufenen Zertifikate herunterladen, sondern können gezielt eine Anfrage für das betreffende Zertifikat an den Online Responder stellen. Für eine detailliertere Beschreibung siehe Artikel "Grundlagen Online Responder (Online Certificate Status Protocol, OCSP)".

Mögliche Ursachen für den Ausfall des Online Responders können unter Anderem sein:

Signaturzertifikat abgelaufen
Signaturzertifikat hat keinen Zugriff auf den privaten Schlüssel
Die zugrundeliegende Sperrliste ist abgelaufen
Der Server, auf welchem der Onlineresponder installiert ist, ist offline
Der Onlineresponder-Dienst ist nicht gestartet
Keine Netzwerkverbindung zum Onlineresponder

Details: Das Signaturzertifikat ist abgelaufen

Hier muss zwischen einer Online- und einer Offlinekonfiguration unterschieden werden. Bei einer Online-Konfiguration beantragt und erneuert der Onlineresponder automatisch seine Signaturzertifikate von der zuständigen Zertifizierungsstelle. Schlägt dies fehl, protokolliert der Onlineresponder das Ereignis Nr. 34.

The Online Responder Service encountered an error while submitting the enrollment request for configuration Fabrikam Issuing CA 1 (Key 0) to certification authority adcsca02.corp.fabrikam.com\Fabrikam Issuing CA 1. The request ID is -1.(The RPC server is unavailable. 0x800706ba (WIN32: 1722 RPC_S_SERVER_UNAVAILABLE))

Wenn (bei einer Onlinekonfiguration) kein neues Signaturzertifikat beantragt werden konnte, oder (bei einer Offlinekonfiguration) das Signaturzertifikat nicht durch einen Administrator ersetzt wurde, kann der Onlineresponder nach Ablauf des aktuellen Signaturzertifikats kein neues mehr finden und protokolliert das Ereignis Nr. 23.

The Online Responder Service could not locate a signing certificate for configuration Fabrikam Issuing CA 1 (Key 0).(Cannot find the original signer. 0x8009100e (-2146889714 CRYPT_E_SIGNER_NOT_FOUND))

Details: Signaturzertifikat hat keinen Zugriff auf den privaten Schlüssel

Wenn beispielsweise ein Hardware Security Modul (HSM) zum Einsatz kommt und dieses ausfällt oder nicht erreichbar ist, kann es sein, dass das Signaturzertifikat mangels Zugriff auf dessen privaten Schlüssel nicht mehr verwendet werden kann.

Leider protokolliert der Onlineresponder in diesem Fall keine eigene Fehlermeldung, jedoch wird auf dem Server ein "Application Error" mit der Event ID 1000 und der Anwendung "ocspsvc.exe" protokolliert. In diesem Beispiel wurde ein Utimaco HSM mit dem Utimaco CryptoServer Key Storage Provider (KSP) verwendet und die Verbindung zum HSM unterbrochen. Wie man sieht, taucht der KSP als fehlgeschlagenes Modul "cs2cng.dll" auf.

Faulting application name: ocspsvc.exe, version: 10.0.17763.1, time stamp: 0x0b55b209
 Faulting module name: cs2cng.dll, version: 2.0.2.0, time stamp: 0x58d17a42
 Exception code: 0xc0000005
 Fault offset: 0x000000000000b366
 Faulting process id: 0x8cc
 Faulting application start time: 0x01d664b59aa01c1d
 Faulting application path: C:\Windows\system32\ocspsvc.exe
 Faulting module path: C:\Windows\system32\cs2cng.dll
 Report Id: 855352a9-dd83-4a7e-97c7-a311c5e7e04a
 Faulting package full name: 
 Faulting package-relative application ID:

Dieses Ereignis wird nur einmal erzeugt. Es tritt jedoch im Kombination mit dem Ereignis 1001 der Quelle "Windows Error Reporting" auf.

Fault bucket , type 0
 Event Name: APPCRASH
 Response: Not available
 Cab Id: 0
 Problem signature:
 P1: ocspsvc.exe
 P2: 10.0.17763.1
 P3: 0b55b209
 P4: cs2cng.dll
 P5: 2.0.2.0
 P6: 58d17a42
 P7: c0000005
 P8: 000000000000b366
 P9: 
 P10: 
 Attached files:
 These files may be available here:
 \?\C:\ProgramData\Microsoft\Windows\WER\ReportQueue\AppCrash_ocspsvc.exe_11cd50d9bebf65b386bcdd298333781d4fd3c769_1cf9278b_073ccd0b
 Analysis symbol: 
 Rechecking for solution: 0
 Report Id: 855352a9-dd83-4a7e-97c7-a311c5e7e04a
 Report Status: 4100
 Hashed bucket: 
 Cab Guid: 0

Die Sperrprüfung auf dem Client wird für den Onlineresponder melden, dass die OCSP-Anfrage fehlgeschlagen ist.

Da dem Onlineresponder noch ein Internet Information Services (IIS) Dienst vorgeschaltet ist, der bereits erstellte OCSP-Antworten zwischenspeichert, kann es zu dem Phänomen kommen, dass einige Anfragen noch (aus dem Cache) bedient werden, andere jedoch nicht (da sie nicht signiert werden können).

Details: Die zugrundeliegende Sperrliste ist abgelaufen

Läuft die zugrundeliegende Basis- oder Deltasperrliste ab, protokolliert der Onlineresponder das Ereignis Nr. 17, welches überwacht werden kann:

For configuration test, Online Responder revocation provider either has no CRL information or has stale CRL information.

Die Sperrprüfung auf dem Client wird für den Onlineresponder melden, dass die OCSP-Antwort abgelaufen ist.

Clientseitiges Verhalten bei der Überprüfung des Sperrstatus

Seit Windows Vista (Windows XP unterstützte noch kein OCSP) ist das Verhalten wie folgt:

Wenn eine OCSP Adresse in der Authority Information Access (AIA) Erweiterung des Zertifikats steht, wird diese bevorzugt für die Überprüfung des Sperrstatus verwendet (näheres hierzu: Warum steht der Onlineresponder (OCSP) in der Authority Information Access (AIA) Erweiterung und nicht in den Sperrlistenverteilpunkten (CDP))
Wenn keine OCSP Adresse in der AIA Erweiterung steht oder der Onlineresponder nicht verfügbar ist bzw. nicht funktioniert, werden die Adressen im CRL Distribution Point (CDP) in exakt der Reihenfolge abgearbeitet, wie sie im Zertifikat stehen.

Für alle Adressen gilt, je nach Konfiguration durch die Anwendung, ein Timeoutwert:

Kumulativer Timeout (Standardeinstellung): Insgesamt stehen in der Standardeinstellung 20 Sekunden für die Sperrstatusüberprüfung zur Verfügung. Die erste Adresse erhält einen Timeoutwert von 10 Sekunden, jede weitere Adresse erhält 50% der verbleibenden Zeit bis sie in einen Timeout läuft.
Wählt die Anwendung nicht den kumulativen Timeout, beträgt der Timeoutwert 15 Sekunden pro Adresse.

Die hier getroffenen Aussagen gelten nur für Anwendungen, die die Microsoft CAPI2 (Cryptographic Application Programming Interface, CryptoAPI Version 2.0) verwenden. Für eine Liste von gängigen Anwendungen, auf welche dies zutrifft, und auf welche nicht, siehe Artikel: "Welche gängigen Anwendungen verwenden die CAPI2 und welche nicht?".

Resiliente Kombination aus OCSP und CDP

Basierend auf diesem Verhalten kann eine Kombination aus einem Onlineresponder, welcher eine Deltasperrliste verwendet und einem CRL-Verteilungspunkt, welcher diese nicht verwendet, etabliert werden, um eine akzeptable Kombination aus schneller Sperrstatusprüfung sowie erhöhter Ausfallsicherheit zu erreichen. Für weitere Details siehe Artikel "Kombination OCSP mit Delta CRL und CDP ohne Delta CRL für gesteigerte Resilienz".

Die hier beschriebene Konfiguration funktioniert zwar in der Praxis, wurde jedoch nicht vom Hersteller (Microsoft) getestet und wird daher nicht offiziell unterstützt.

Weiterführende Links:

Externe Quellen

How Certificate Revocation Works (Microsoft)