Online Certificate Status Protocol


Online Certificate Status Protocol or OCSP is a HTTP protocol that allows a Relying Party to submit a certificate status request to an OCSP Responder

Online Certificate Status Protocol returns a definitive, Digitally Signed response indicating the certificate status. The amount of data retrieved per request is constant regardless of the number of Revoked Certificates in the Certificate Authority.

Many OCSP Responders get their data from published CRLs and are therefore reliant on the publishing frequency of the CA.

is used by browser software to query a Certificate Authority dynamically checking Certificate Revocation when performing Certificate Validation

The query request contains the serial number of the Certificate being checked as well hashes of the issuer name and Public Key. The request is sent to a Online Certificate Status Protocol server operated by the Certificate Authority. The response will either indicate that the certificate is:

  • valid,
  • revoked
  • unknown
When using Online Certificate Status Protocol, the final check for a certificate’s validity is to verify that the Certificate Authority’s Online Certificate Status Protocol server reports back that the certificate is ‘valid’.

Validation with Online Protocols#

To solve the problems of Certificate Validation in an efficient manner the PKIX working group of the IETF (The Internet Engineering Task Force) proposed a Online Certificate Status Protocol (OCSP) in June 1999 and finalized another flavor of Online Certificate Validation by releasing the Server-Based Certificate Validation Protocol (SCVP) in 2003.

These protocols allows a client to request informations regarding the validity of one or more Certificates which will be answered (and digitally signed) by a so called responder.

The Online Certificate Status Protocol method to do certificate validation implicates two major improvements.

  • The first and foremost is an efficient risk management as an online-responder is able to provide real-time status information to the user.
  • The second improvement that this protocol lessens the network traffic significantly, as users do not receive a huge list (as they do when using Certificate Revocation Lists, needing only a few entries but only get the information they need. To ensure a maximum compatibility with the various networks, HTTP is used to transport the request and the response between a client and the responder.

Most e-commerce systems developed a lot of interest in this technology. This is not only because these protocols provide real-time validation and therefore allow them to setup an effective risk management, but also because of billing issues. The request of an online validation is the only communication between the "seller" in an e-commerce system and the system provider that occurs for every transaction. Thus the number of validation requests can be the basis for billing per request. By using this kind of billing system, the seller of a product in an e-commerce system is billed and not the "buyer" (end-user) as it is the case by selling certificates.

Drawbacks with Online Certificate Status Protocol#

The paper Towards Short-Lived Certificates[1] identifies following four drawbacks in Online Certificate Status Protocol.
  • OCSP validation increases client side latency because verifying a certificate is a blocking operation, requiring a round trip to the OCSP responder to retrieve the revocation status (if no valid response found in cache). A previous study indicates that 91.7% of OCSP lookups are costly, taking more than 100ms to complete, thereby delaying HTTPS session setup.
  • OCSP may provide real-time responses to revocation queries, however it is unclear whether the responses actually contains updated revocation information. Some OCSP responders may rely on cached CRLs on their backend. It was observed that DigiNotar’s OCSP responder was returning good responses well after they were attacked.
  • Similar to CRLs, there are also multiple ways that an OCSP validation can be defeated, including traffic filtering or forging a bogus response by a network attacker. Most importantly, revocation checks in browsers fail open. When they cannot verify a certificate through OCSP, most browser do not alert the user or change their UI, some do not even check the revocation status at all. We note that failing open is necessary since there are legitimate situations in which the browser cannot reach the OCSP responder.
  • OCSP also introduces a privacy risk: OCSP responders know which certificates are being verified by end users and thereby responders can, in principle, track which sites the user is visiting. OCSP stapling is intended to mitigate this privacy risk, but is not often used. OCSP Stapling is intended to mitigate this privacy risk, but is not often used.

Google has disabled OCSP in Chrome and instead uses CRLSets which uses its existing software update mechanism to maintain a list of revoked certificates.

More Information#

There might be more information for this subject on one of the following: