Effects of the failure of the online responder (OCSP) on the verification of the revocation status of a certificate

Author Uwe GradeneggerPosted on Categories Online Certificate Status Protocol (OCSP), TroubleshootingTags

The following section examines how the revocation status check behaves if the online responder should fail. Depending on the configuration of the certificates issued, the behavior can vary considerably.

The Online Responder (Online Certificate Status Protocol, OCSP) is an alternative way of providing revocation status information for certificates. Entities that want to check the revocation status of a certificate do not have to download the complete list of all revoked certificates thanks to OCSP, but can make a specific request for the certificate in question to the online responder. For a more detailed description, see the article "Basics Online Responder (Online Certificate Status Protocol, OCSP)„.

Possible causes for the failure of the online responder can be, among others:

  • Signature certificate expired
  • Signing certificate has no access to the private key
  • The underlying blacklist has expired
  • The server on which the online responder is installed is offline
  • The online responder service has not started
  • No network connection to the online responder

Details: The signing certificate has expired

A distinction must be made here between an online and an offline configuration. In an online configuration, the online responder automatically requests and renews its signature certificates from the responsible certification authority. If this fails, the online responder logs the Event no. 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))

If (in case of an online configuration) no new signature certificate could be requested, or (in case of an offline configuration) the signature certificate was not replaced by an administrator, the online responder cannot find a new one after the current signature certificate has expired and logs the Event no. 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: Signing certificate has no access to the private key

For example, if a hardware security module (HSM) is used and it fails or is unavailable, the signing certificate may no longer be usable due to lack of access to its private key.

Unfortunately, the online responder does not log its own error message in this case, but an "Application Error" with event ID 1000 and the application "ocspsvc.exe" is logged on the server. In this example, a Utimaco HSM was used with the Utimaco CryptoServer Key Storage Provider (KSP) and the connection to the HSM was broken. As you can see, the KSP shows up as a failed module "cs2cng.dll".

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: 0xc00005
 Fault offset: 0x00000000b366
 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:

This event is generated only once. However, it occurs in combination with event 1001 of the "Windows Error Reporting" source.

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: 0000000000b366
 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

The lock check on the client will report for the online responder that the OCSP request failed.

Since the online responder is still preceded by an Internet Information Services (IIS) service that caches OCSP responses that have already been created, the phenomenon can occur that some requests are still served (from the cache), but others are not (since they cannot be signed).

Details: The underlying blacklist has expired

If the underlying base or delta brevocation list expires, the online responder logs event no. 17, which can be monitored:

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

The lock check on the client will report for the online responder that the OCSP response has expired.

Client-side behavior when checking the revocation status

Since Windows Vista (Windows XP did not support OCSP yet) the behavior is as follows:

For all addresses, depending on the configuration by the application, a timeout value applies:

  • Cumulative timeout (default setting): A total of 20 seconds is available for the revocation status check in the default setting. The first address receives a timeout value of 10 seconds, each additional address receives 50% of the remaining time until it times out.
  • If the application does not select cumulative timeout, the timeout value is 15 seconds per address.

The statements made here apply only to applications that use the Microsoft CAPI2 (Cryptographic Application Programming Interface, CryptoAPI version 2.0). For a list of common applications to which this applies and to which it does not, see the article: "Which common applications use CAPI2 and which do not?„.

Resilient combination of OCSP and CDP

Based on this behavior, a combination of an online responder that uses a delta revocation list and a CRL distribution point that does not can be established to achieve an acceptable combination of fast blocking status checking as well as increased resilience. For more details, see the article "Combination OCSP with Delta CRL and CDP without Delta CRL for increased resilience„.

The configuration described here works in practice, but has not been tested by the manufacturer (Microsoft) and is therefore not officially supported.

Related links:

External sources

en_USEnglish
de_DEDeutsch en_USEnglish