How a CRL (Certificate Revocation List) Works

Certificate Revocation List, or CRL, is a digital record published by Certification Authorities (CAs)

That contains information about the revoked certificates, which assists in real-time checking whether the SSL Certificate has been revoked.

How does CRL work?

The Certificate Revocation List is published by the Certificate Authority (CA) which has issued the SSL certificate. Here’s how a certificate is revoked using a CRL:

1. A reason arises why the certificate should be revoked, for example:
   • Private key lost/stolen or compromised
   • Company name or other data is incorrect
   • Malware/fishing
   • Issuing Certification Authority is compromised
   • SSL was issued with incorrect parameters
   • Revocation request received from the domain owner
2. The CA enters the unique serial number of the certificate into the CRL list, which is signed with the CA’s digital signature and cannot be changed
3. Each time the visitor’s browser connects to the resource, the browser has to check to if the SSL certificate has been revoked. It sends the request to CA and downloads the actual CRL list. If it finds the certificate in the CRL list or receives a response from the CA that the certificate has been revoked, the browser displays an error warning.

The screenshot above shows the SSL certificate’s distribution point. In that example, the certificate is issued by Sectigo CA, which provides only one distribution point.

Failure of SSL revocation status verification using CRL

There are some imperfections in the revocation status verification procedure using CRL technology.

The major disadvantage of CRL is that it is not updated frequently enough, usually once a day, which is an ineffective security measure, for example, against an attacker who has obtained someone else’s Private Key.

What are some other reasons why certificate revocation checking using CRL may fail?

• The CRL cannot be reached or is not available.
• The CA listed in the CRL does not match the certificate issuer
• The certificate revocation list is not up-to-date

Due to this, some browsers use alternative solutions to check if the SSL/TLS certificate has been revoked. For example, Safari uses OCSP by default and refers to CRL only if OCSP servers are not available.

Any alternative? OCSP

One of the most popular alternatives is OCSP – Online Certificate Status Protocol. This solution provides a real-time response from the server about the particular certificate. This approach solves many of the problems inherent in CRL by responding with a single record. In contrast, the CRL-based model requires verifying parties to repeatedly retrieve a huge number of irrelevant records to obtain information for the one certificate they need. OCSP works differently and only produces a response for a specific request.

We don’t say that the operation of OCSP is better. It is just different. The CRL, in its response to a browser request, gives a whole list of revoked certificates, while OCSP only gives a response for a specific certificate. This can be “good”, “revoked”, or “unknown”.

You have probably heard the term OCSP stapling. Let’s go over what it is. In plain words, it is the OCSP response along with the certificate itself. This is called OCSP Stapling because the server is supposed to “staple” the OCSP response to the certificate and issue them together. However, this is not widely implemented, and only 3% of servers support OCSP Stapling.