Online Certificate Status Protocol (OCSP) vs Certificate Revocation Lists (CRLs)

Online Certificate Status Protocol (OCSP) and Certificate Revocation Lists (CRLs) are two methods of maintaining Certificate Lifecycle Management (CLM) for your organization. But before getting into which method is the best, let’s discuss why you should be even using CLM in the first place.

As you might know, when using HTTP/S in the websites managed by organizations, SSL certificates are deployed which organizations gain from a Certificate Authority(CA) which validates if the certificate is legitimate or not. These certificates however, have a validity period for which they stay active and encrypt all the communications to and from the server protecting user activity online from bad actors and Man in the Middle (MitM) attacks.

After expiration of the said certificate, a new certificate has to issued and the previous certificate has to be blacklisted so that it is not used for any future communications. To maintain records of such activities, organizations are required to use CLM.

OCSP

Online Certificate Status Protocol (OCSP) is an Internet protocol which enables applications to determine the revocation state of identified certificates without the use of Certificate Revocation Lists (CRLs). With OCSP, it is possible to gain more timely information of the revocation status than is possible with CRLs.

How it works

An OCSP client sends a status request to an OCSP responder and waits to accept the certificates until the responder provides a response.

OCSP Request

An OCSP request contains the following information:

1. Protocol version
2. Service request
3. Target certificate identifier
4. Other optional extensions.

Upon receiving the request, the OCSP responder checks if the predefined conditions are met. These conditions are:

1. The message should be well formed.
2. The responder should be configured to provide the requested service.
3. The request should contain the information needed by the responder.

It returns a definitive response if all of the above conditions are met, and produces an error message otherwise.

OCSP Response

An OCSP response can be of various types, but there is only one kind of OCSP response is supported by all OCSP servers and clients. A basic OCSP response contains the following information:

• Version of the response syntax
• Identifier of the responder
• Time when the response was generated
• Responses for each of the certificates in a request
• Optional extensions
• Signature algorithm OID
• Signature computed across a hash of the response

There are 3 certificate status values that can be returned:

• Good

  A certificate status of “good” shows that the certificate is valid for use. At a minimum, this shows that a certificate with the corresponding serial number and validity period hasn’t been revoked.

• Revoked

  The “revoked” state indicates that the certificate has been revoked, either temporarily or permanently. If the CA has no record of ever having issued a certificate with the certificate serial number in the request, then this status may also be returned.

• Unknown

  The “unknown” state indicates that the responder doesn’t know about the certificate being requested, usually because the request indicates an unrecognized issuer that is not served by this responder.

The OCSP response is always signed by the CA to ensure no alteration occurs while the request is in transit.

OCSP Stapling

OCSP Stapling improves performance by setting up a digitally-signed and time-stamped OCSP response on the webserver.  This OCSP response is then refreshed at certain intervals set by the CA. The stapled OCSP response lets the web server include the OCSP response within the initial SSL handshake, without the user needing to make a separate connection to the CA.

Advantages

• When compared to the CRL, an OCSP response contains considerably less data as by using OCSP a client can query the status of a single certificate rather than having to download and parse an entire list.
• Since the data requested is low, the load on the client and network is considerably lower than with CRLs.

Disadvantages

• Since the request is sent for each certificate every single time, it can overload the OCSP responder for high traffic websites.
• Although the above can be solved by using OCSP Stapling, it is not yet supported by all the browsers.
• If the private key for the server was compromised, an attacker can pose as the server using an Man in the Middle attack.

CRL

A Certification Revocation List (CRL) is a list of digital certificates that have been revoked by the issuing Certificate Authority (CA) before their scheduled expiration date and should no longer be trusted. There are two different states of revocation defined:

Revoked

In this state, a certificate is revoked irreversibly and cannot be reinstated. The reason for revocation could be any of the following:

• Unspecified
• Key Compromise
• CA Compromise
• Affiliation Changed
• Superseded
• Cessation of Operation
• Certificate Hold
• Removed from CRL
• Privilege Withdrawn
• CA Compromise

The most common reason for revocation is that the private key for the user has been compromised.

Hold

A certificate that is put into a hold state is suspended temporarily and may be reinstated if needed. Putting a certificate on hold could occur for several reasons, for example if a private key that was previously thought to be lost was found, the status can be reinstated and the certificate will become valid again.

How it works

A CRL essentially functions as a blacklist for certificates. A browser  makes a GET request to an HTTPS enabled page, the CA receives the request, and then returns a list of all the revoked certificates.  The browser then parses the CRL to ensure that the certificate of the requested site isn’t contained within it.

When a browser wants to retrieve a CRL for a certificate, it retrieves it from a specified CRL Distribution Point (a CRL Distribution Point (CDP) is an X.509 v3 certificate extension). To put it in simple terms, a CRL distribution point is a shared location on the network that is used to store the CRL and certificates. It is also possible to have two distribution points, one pointing to the HTTP CRL location with the other pointing to the LDAP CRL location. Both distribution points HTTP and LDAP could be pointing to the same CRL.

Advantages

Using a CRL is the next best way of maintaining a certificate lifecycle if, for some reason, OCSP is not available.

Disadvantages

• Generally, the CRL returned contains thousands of line, which can cause a considerable effect on the network and client performance.
• Typically the publishing of a new CRL is very slow, which can leave the client open to attacks.
• If for some reason a client is unable to download the CRL, it’ll default to trusting the certificate.