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

What is a digital certificate?

Digital certificates are used in the encryption process to secure communications and create trust in online transactions — most often, by using the Transport Layer Security (TLS)/Secure Sockets Layer (SSL) protocol. The certificate, which is signed by the issuing CA, also provides proof of the certificate owner’s identity.

When a web browser connects to a site using TLS, its digital certificate is checked for anomalies or problems. Part of this process involves checking that the certificate is not listed in a CRL.

These checks are crucial for certificate-based transactions because they allow a user to verify the identity of the site owner and discover if the digital certificate is trustworthy.

How does a CRL check work?

Here’s how the CRL authentication process works:

• A user (client) submits their digital certificate through the access point.
• The access point sends the certificate to the authentication server for authentication.
• The server checks to see if the certificate is expired.
• If the certificate is valid (i.e., not expired), the server checks the directory containing the details of approved users.
• If the user is found in the directory, the server next checks the CRL to confirm if the certificate is revoked (identified by the certificate serial number).
• If the certificate is not revoked, i.e., the serial number is not in the CRL, the user is allowed to access the network.

Why is a certificate revocation list important?

The main purpose of a CRL is for CAs to make it known that a site’s digital certificate is not trustworthy. It warns a site’s visitors not to access the site, which might be fraudulently impersonating a legitimate site.

A CRL also protects visitors from man-in-the-middle attacks.

In the absence of a CRL, a visitor might access a potentially risky site, leaving them vulnerable to the following:

Certificate revocation list and the public key infrastructure

CRLs play an important role in the public key infrastructure (PKI), a system that uses public key encryption and digital certificates to facilitate secure information exchange between entities (users, computers, servers and browsers) over the internet.

Without a CRL, the PKI wouldn’t know whether a certificate is not trustworthy, potentially compromising the integrity of the PKI system.

Relying on a CRL that contains the latest revoked certificates, the PKI system can prevent malicious parties from using untrustworthy certificates for fraudulent activities. This helps ensure the security of the network, maintains transactional integrity, protects users, and ultimately, allows certificate-verifying entities to maintain trust in the PKI.

What does a certificate revocation list include?

The X.509 PKI standard defines the format and semantics of a CRL for a PKI. Each entry includes the revoked certificate’s unique serial number and revocation date. It may also include a time limit, whether the revocation applies for a limited or specific time period, and a reason for the revocation (along with the specific revocation code).

Other information in a CRL might include: CRL issuer (CA) information, next update time for the CRL, and the CA’s digital signature.

What defines a certificate revocation list?

According to the National Institute of Standards and Technology (NIST), a CRL is a list maintained by a CA of the certificates it has issued and revoked prior to their stated expiration date. CRLs contain certificates that have either been irreversibly revoked or marked as temporarily invalid (hold).

The CRL does not include expired certificates, i.e., certificates that have reached the end of their predetermined lifecycle (typically one to five years). This is because expired certificates automatically become invalid but are not necessarily deemed untrustworthy by the CA. Expired certificates that are already on a CRL are automatically removed when they expire. Also, the CRL issuer (third party) might not be the same entity as the CA that issued the revoked certificate.

Why does a digital certificate get revoked?

X.509 digital certificates play a vital role in PKI and web security. Every TLS/SSL certificate has a finite validity period. However, it could be revoked — a process known as PKI certificate revocation — before its validity period ends for many reasons.

For example, a CA might discover that it improperly issued a certificate, revoke the original certificate and reissue a new one. Or it might discover that a certificate is counterfeit, in which case it will be revoked and added to the CRL. The most common reason for revocation is when a certificate’s private key has been compromised.

Other reasons for revoking a certificate include the following:

• The issuing CA has been compromised.
• The certificate owner no longer owns the domain for which it was issued.
• The certificate owner has ceased operations entirely.
• The original certificate has been replaced with a new certificate.
• The person that the certificate was issued to has left the organization that owns the certificate.
• The certificate owner’s legal name has changed.
• The certificate owner’s network privileges have been revoked.
• Temporary revocation.

Each of the above reasons is associated with a specific revocation code (also known as a reason code). For example, the revocation code keyCompromise is used if the certificate’s private key was compromised and the code superseded is used if the user’s information has changed.

What are the drawbacks of certificate revocation lists?

One of the problems with CRLs is they’re difficult to maintain. CRLs are also an inefficient method of distributing critical information about the trustworthiness of digital certificates in real time. Lags in CA updates to the CRL could compromise users and leave them susceptible to security risks over the internet.

CRLs are often updated weekly or daily and, in some cases, hourly. However, any time gap could allow a revoked certificate to be accepted, particularly because CRLs are cached to avoid incurring overhead due to repeated downloads. Also, if the CRL is unavailable, then any operations that depend on certificate acceptance will be prevented, and that might lead to a denial-of-service (DoS) attack.

When a CA receives a CRL request from a browser, it returns a complete list of all the revoked certificates that the CA manages. The browser must then parse the list to determine if the certificate of the requested site has been revoked. Delays here also increase security risks.

The risk of other security vulnerabilities is due to the way different browsers handle CRLs. Determining the method used to check certificate revocation status can vary by browser and, in some instances, depends on which operating system the browser is running. Unless it is an Extended Validation Certificate, some browsers only check the validity of the server’s certificate, not the entire chain of certificates required for validation. Also, if a browser only supports CRLs delivered in the standard binary format, it might not be able to process CRLs in a different text-based format.

For example, Mozilla Firefox and Google Chrome on Linux support CRLs delivered in the standard binary format, but they cannot process RSA Security’s CRLs because they’re in a text-based format. Due to this mismatch, it might allow the connection without providing a warning, jeopardizing the security of the user and the transaction.

Certificate revocation lists vs. certificate transparency logs

Although CRL and certificate transparency logs (CT logs) both deal with X.509 digital certificates, and are often mistaken for each other, they’re two separate processes and serve two different functions.

A CT log is like a certificate inventory for a particular domain. It only records the certificates issued for that domain and doesn’t provide information about whether a certificate is revoked.

This is exactly the purpose of the CRL. Moreover, the CRL only lists the revoked certificates. It does not list all the certificates issued for that domain.

Certificate revocation lists vs. Online Certificate Status Protocol

The Certificate Authority Security Council — whose members include leading CAs — wants to promote the importance of certificate-revocation checking, and the adoption and deployment of Online Certificate Status Protocol (OCSP) stapling as an alternative to the use of CRLs.

Many of the drawbacks of CRLs can be mitigated with OCSP.

OCSP is an internet protocol described in IETF RFC 6960 and used to request the revocation status of a digital certificate.

Instead of having to download the latest CRL and check whether a requested URL (Uniform Resource Locator) is on the list, the browser sends the certificate for the site in question to the CA who returns a value of “good,” “revoked” or “unknown” for that certificate. OCSP stapling eliminates the need for a browser to request the OCSP response directly from the CA. Instead, when the website sends its certificate to the browser, it attaches (staples) its OCSP response.

OCSP involves two parties: an OCSP client (the requester of the revocation status) and the OCSP responder (the server providing the revocation information through an OCSP response). The OCSP response is signed by the owning (or designated) CA rather than the PKI, which speeds up the process of providing revocation information.

This approach transfers far less data, which doesn’t need to be parsed before it can be used. It also protects the end user’s privacy because the CA only sees requests from websites, not the website’s end users. Most major web servers and browsers all support OCSP stapling, and support for its use is growing.

That said, OCSP is less secure than CRL because it does not require encryption and because it is susceptible to replay attacks. Also, the fact that an OCSP response only returns one of three values for a certificate (good/revoked/unknown) makes it less informative than CRLs.

Safeguarding authenticity of online communications is essential to running a business. Learn how to use a public key and private key in digital signatures to manage electronic documents.