Basics Online Responder (Online Certificate Status Protocol, OCSP)

Certificates usually have a "CRL Distribution Points" extension that tells an application where the certificate's associated Certificate Revocation List (CRL) can be found.

This is like a telephone directory: It contains all the serial numbers of certificates that have been recalled by the certification authority (and are still valid). Every application that checks the revocation status must download and evaluate the entire revocation list.

As the size increases, this procedure becomes increasingly inefficient. As a rule of thumb, 100,000 recalled certificates already correspond to approx. 5 MB file size for the revocation list.

The Online Certificate Status Protocol (OCSP) was developed for this purpose (under the leadership of ValiCert): It is similar to a directory assistance service where applications can request the revocation status for individual certificates, thus eliminating the need to download the entire CRL. OCSP is available in the RFC 6960 specified.

Sometimes it is necessary for a certificate issued by a certification authority to be withdrawn from circulation even before its expiration date. To make this possible, a certification authority keeps a revocation list. This is a signed file with a relatively short expiration date, which is used in combination with the certificate to check its validity.

Functionality

Instead of downloading a (supposedly large) CRL, a client queries the revocation status for each certificate to be checked from the online responder and receives a signed response as to whether the certificate has been revoked or not. If the revocation list is a phone book, OCSP is thus the information to which targeted specific queries can be sent.

In the Microsoft implementation, OCSP again uses CRLs as a database. This means that there is no direct connection to the certification authority database, and by default the responder cannot determine whether a requested certificate has actually been issued by the certification authority (Deterministic "Good).

The availability of OCSP can be specified within the Authority Information Access (AIA) attribute in an issued certificate or configured globally on the checking computer can be used. The OCSP extension is located under AIA, since the online responder is also an authority (Validation Authority, VA).

If an OCSP address is present in the certificate to be checked, this is preferred by modern Windows operating systems over revocation lists. This behavior thus applies to all Windows applications that use the Microsoft CAPI to check certificates.

Disadvantages when using OCSP

However, OCSP brings some disadvantages along with its advantages:

OCSP is often understood as a security feature due to the supposedly real-time blocking check, but it is merely a tool for improving the performance of the blocking state infrastructure, since there is no guarantee that the client will not ultimately fall back on the revocation list after all. That being said, OCSP responses also have a validity period, just like a blacklist. The end date for this validity period is taken 1:1 from the underlying revocation list.
OCSP is location dependent, i.e. in a distributed infrastructure all clients would connect to the central online responder over potentially slow and failure-prone WAN lines, which can effectively even increase CRL check time as well as network load.

However, it may well be worth considering implementing OCSP even though it is not (yet) needed from the current point of view. Should the need arise in the future to revoke a very large number of certificates in a short period of time, as was the case with the Heartbleed incident, the revocation check via revocation lists would quickly reach the limit of its capabilities.

On the usefulness of using OCSP

OCSP is an additional IT service that ties up human, technical and financial resources. In view of the fact that "live" blocking (desired in many cases) is not feasible, the question arises as to when the use of OCSP makes sense.

Reasons for this may be:

Auditing, if done correctly (see article "Force domain controller (or other participants) to use an online responder (OCSP)" for an application example).
Performance with a large number of (expected) revoked certificates and correspondingly large certificate revocation lists. In most environments, however, these sizes will never be reached in practice.
As an emergency option. Should the need arise in the future to revoke a large number of certificates at once, as was the case with the Heartbleed vulnerability, for example. But as already mentioned, most environments tend not to exceed the break-even point at which OCSP is more efficient than a revocation list.
Application-specific peculiarities can make the use of an online responder useful: For example, when creating document signatures, Adobe Reader and Adobe Acrobat use the OCSP response (if any) for the signing certificate at the time of signing as proof that the certificate was valid at that time.

Please also note that Google Chrome and the Chromium-based Microsoft Edge (codenamed Anaheim), by default anyway. Do not perform a revocation status check.

Pitfalls

It cannot be guaranteed that OCSP will be used due to various influencing factors.

These include:

Magic Number
Client implementations or settings that may override the certificate content

Magic Number

The Magic Number is proprietary to the implementation of OCSP in the Windows ecosystem.

Microsoft Windows (the Microsoft CAPI) offers the special feature of a "magic number", i.e. a counter that is incremented for each certificate authority. If the counter is exceeded and the certificate also has a revocation list distribution point (CDP), this is used for future requests for efficiency reasons. See article "Configure the "Magic Number" for the online responder„.

Locking information is not "live": the client-side cache

Both CRLs and OCSP responses are cached by Microsoft CryptoAPI / CAPI for the period of their validity.

This statement applies to applications that use the CryptoAPI / CAPI on Windows, such as Internet Explorer, Edge or Google Chrome. However, the behavior may differ for other applications (e.g. Mozilla Firefox) or operating systems.

On Windows operating systems, there are two types of caches for locking information:

Hard disk cache. This cache can be used by all applications and is persistent, i.e. available even after a restart of the computer.
Working memory cache. This cache is application-specific and only exists during the runtime of the application. If the application is terminated, this cache is also deleted.

OCSP was not developed as a security feature but as an efficiency and thus performance feature. The OCSP response is valid (in the Microsoft implementation) exactly as long as the underlying blacklist.

Locking information is not "live": the server-side cache

For reasons of efficiency, the Microsoft online responder is preceded by a cache in the IIS web server, which keeps OCSP responses signed once during their validity period so that they do not have to be re-signed for further requests for the same certificate and load on the server and any existing Hardware Security Module (HSM) generate. This circumstance also contradicts the assumption of a live revocation status check.

Significance of the OCSP responses

Since the Microsoft online responder uses revocation lists as a database, it has no information about whether a requested certificate for which no revocation status could be determined was actually issued by the certification authority and can be found in its database.

However, there is the possibility of Serial numbers of the certificates to be checked additionally against a list of certificates issued by the certification authority, in order to be able to use the private key directly (see article "Signing certificates bypassing the certification authority") the Certification Authority issued certificates to detect and possibly trigger an alarm.

See article "Configure deterministic "good" for the online responder (OCSP)." for more information.

OCSP response signing certificates cannot be revoked

The OCSP signing certificate must not contain any revocation status information to avoid a loop situation (the revocation status would eventually be checked again by OCSP).

Therefore, OCSP response signing certificates are certificates that require special protection, and are issued with either a Hardware Security Module (HSM) should be protected or at least have a very short certificate term.

Therefore, in the default setting of Microsoft Online Responder, signing certificates are valid for only 14 days and are automatically renewed by the online responder service (two days before their expiration).

The online responder should be a domain member in order to be managed in a meaningful way

Another disadvantage becomes apparent here: if the online responder servers are not to be located in the same Active Directory as the certification authorities (if they are, one creates a bridge from the Internet to the online certification authorities in the case of online responders connected to the Internet), the OCSP password signing certificates cannot be renewed automatically. Manual renewal at two-week intervals is also not practical.

Even if hardware security modules are used, the validity of an OCSP password signature certificate should not exceed a few months. So there is no way around renewing the certificates manually (or scripted, if necessary) on a regular basis in this case. This manual process is again a risk for the availability of the online responder (see below).

HTTPS is possible, but not useful

OCSP requests are transmitted via the HTTP protocol. Often, for compliance reasons, it is desired that all HTTP traffic be protected via SSL (or TLS) (HTTPS).

Although this is theoretically possible, it only offers disadvantages, since the blocking status of the SSL-required Web server certificate again would have to be checked, and ultimately no SSL can be used here. There are no advantages because no confidential information is transmitted. Tamper protection is provided by the fact that OCSP responses are signed by the online responder using the OCSP response signature certificate.

Sequence of an OCSP communication

If an OCSP-enabled application checks the revocation status of a certificate, it evaluates its Authority Information Access (AIA) extension. If there is an entry of the type "On-line Certificate Status Protocol" (object identifier (OID) 1.3.6.1.5.5.7.48.1), the URL stored there is then called up with an OCSP request.

The communication with the online responder is done via HTTP and deliberately without SSL. Both the POST and the GET method can be used here.

HTTP-based OCSP requests can use either the GET or the POST method to submit their requests.
https://datatracker.ietf.org/doc/html/rfc6960#appendix-A.1

The OCSP request includes the "name hash" and the "key hash" (since both "name matching" and "key matching" are possible, see "Basics: Finding certificates and validating the certification path") of the issuing certification authority as well as the serial number of the requested certificate.

If the online responder knows the issuing certification authority, it checks the underlying certificate revocation list of the certification authority to see whether the serial number of the requested certificate is entered there.

The OCSP response is signed with the signature certificate of the online responder. The signature certificate must be signed by the same (certificate authority) key as the certificate to be verified so that the OCSP response is accepted by the requesting system.

The signed response of the online responder contains the status as well as the validity time of the OCSP response.

Status	Description
Good	The certificate is not on a revocation list known to the OCSP responder.
Revoked	The certificate is on a revocation list known to the OCSP responder.
Unknown	The certificate could not be assigned to or was not issued by a certification authority known to the OCSP responder.

If you take a look at the underlying certificate revocation list of the certification authority, you will find the exact same data for start and expiration.

Please note that the times in the shown shell dialog are localized, but in the OCSP response the UTC times are given.

Availability of the online responder

Availability requirements

The requirements for the availability of the online responder depend on various factors:

Availability of alternative methods for revocation status verification.
Use cases that depend on the revocation status.

Applications that use the Microsoft CryptoAPI or CAPI for revocation status fall back to the revocation lists if an online responder is not available. If the certificates to be checked are configured without revocation list distribution points (i.e. OCSP-only), the availability of the online responder must be classified as much more critical.

Some applications (for example, Adobe Reader and Adobe Acrobat for document signatures) use OCSP responses as a time stamp to ensure that document signatures continue to be considered valid after the signature certificate used expires.

Factors influencing availability

The following factors influence the availability of an online responder:

The network infrastructure (e.g. load balancers, network components, connectivity, name resolution, etc.).
Server infrastructure setup (will a cluster or a single server be used?).
Availability of the certification authority and its private keys (both the revocation lists used and the signature certificates for the online responders must be signed by it on a regular basis).
Configuring the OCSP Password Signing Certificate Template (This is configured in the default configuration for a validity period of two weeks and a renewal two days before expiry).

Thus, in the default configuration and depending on the use case, even with a generous configuration of the revocation list validity time and overlap, there would only be a time window of two days in the event of an (assumed) certification authority failure until the online responder fails.

The certificate template for the OCSP answer signature

The default certificate template for the OCSP password signature is configured for a validity period of only two weeks. The background to this short time window is that OCSP answer signature certificates must not contain any revocation status information and it is accordingly not possible to revoke a compromised OCSP answer signature certificate.

Since the OCSP answer signing certificate must always be issued by the associated certificate authority (the same key used to sign the certificate to be verified), no autoenrollment can be used for the certificate request. The Microsoft online responder therefore includes its own certificate request routine. It applies the time window configured in the certificate template for renewing the certificate. Higher resilience can thus be achieved by configuring this time window as large as possible.

Basics of online responders (Online Certificate Status Protocol, OCSP)