What Is a Certificate Revocation List (CRL) and How Does It Work?

Why Are Certificates Revoked?

A CA may revoke a certificate before its expiration date for several reasons, including:

• Private key compromise: The private key has been lost, stolen, or exposed.
• Incorrect certificate information: The certificate contains inaccurate details or was issued in error.
• Changes in ownership or organization details: Information associated with the certificate is no longer valid.
• CA compromise: A security incident involving the Certificate Authority requires affected certificates to be revoked.
• Revocation request: The certificate owner asks the CA to revoke the certificate.

Once revoked, a certificate should no longer be trusted, even if its validity period has not ended.

How Does a CRL Work?

The CRL process generally involves three steps:

1. Certificate revocation: The CA revokes a certificate and records its serial number, revocation date, and, where available, the reason for revocation.
2. CRL publication: The CA adds the revoked certificate to a digitally signed CRL and publishes the updated list. The certificate's CRL Distribution Points extension can specify where the list is available.

In that example, the certificate is issued by Sectigo CA, which provides only one distribution point.

3. Revocation checking: When a client checks a certificate, it can retrieve the CRL, verify its signature and validity period, and check whether the certificate's serial number appears on the list. If it does, the certificate is considered revoked.

CRLs are updated periodically rather than in real time. The frequency of updates depends on the CA's publishing schedule.

What Information Does a CRL Contain?

A CRL typically includes:

• Issuer: The Certificate Authority that issued and signed the list.
• This Update and Next Update: The date and time when the CRL was published and when the next update is expected.
• Revoked certificate entries: The serial numbers and revocation dates of certificates that have been revoked.
• Revocation reason: The reason for revocation, if provided.

There are two common types of CRLs:

• Full CRL: Contains the complete list of certificates revoked by the CA.
• Delta CRL: Contains changes since the last full CRL, reducing the amount of data that needs to be downloaded and processed.

Limitations of CRL Checking

Although CRLs help identify revoked certificates, this method has several limitations:

• Update delays: A certificate may be revoked before the updated CRL is published and distributed.
• Large file size: Full CRLs can become large, increasing download and processing time.
• Availability issues: The CRL distribution point may be temporarily unreachable, preventing clients from retrieving the latest list.
• Outdated information: A client may have a cached CRL that is no longer current.

If a CRL cannot be retrieved or is outdated, the way a browser or application handles the situation depends on its revocation-checking policy. It does not necessarily mean that the certificate will be automatically rejected.

CRL vs. OCSP: What Is the Difference?

The Online Certificate Status Protocol (OCSP) is another method for checking certificate revocation.

Unlike CRL, which provides a list of revoked certificates, OCSP allows a client to request the status of an individual certificate from an OCSP responder. The response typically indicates one of three statuses:

• Good: The responder reports that the certificate has not been revoked.
• Revoked: The certificate has been revoked.
• Unknown: The responder cannot determine the certificate's status.

OCSP responses can also be cached, and their freshness depends on the responder's configuration.

Conclusion

CRL and OCSP are two distinct mechanisms for checking certificate revocation status. They serve the same general purpose but work differently: CRL distributes a list of revoked certificates, while OCSP provides a status response for an individual certificate. Neither mechanism should be treated as simply a variation of the other.

OCSP Stapling is an extension of the OCSP process, not a separate revocation-checking protocol. It allows a web server to obtain a signed OCSP response and include it in the TLS handshake, so clients do not need to contact the OCSP responder directly.

The revocation-checking mechanisms available and used in practice depend on the Certificate Authority, server configuration, and client software.