What is a certificate revocation list?
The CRL file is signed by the CA to prevent tampering.
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/Secure Sockets Layer (TLS/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.
What defines a certificate revocation list?
According to the National Institute of Standards and Technology, a CRL is a list maintained by a certification authority of the certificates it has issued and revoked prior to their stated expiration date. CRLs contain certificates that have either been irreversibly revoked (revoked) or have been marked as temporarily invalid (hold).
The CRL does not include expired certificates. Also, the CRL issuer (third party) may not be the same entity as the CA that issued the revoked certificate.
The X.509 standard defines the format and semantics of a CRL for a public key infrastructure (PKI). Each entry includes the revoked certificate's 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.
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 before its validity period ends for many reasons.
This process is sometimes known as PKI certificate revocation.
For example, a CA may discover that it improperly issued a certificate, revoke the original certificate and reissue a new one. Or it may 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 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 from another issuer
Certificate revocations are not uncommon. In 2019, several CAs, including Apple and Google, revoked millions of certificates because the certificates were mistakenly issued with noncompliant 63-bit serial numbers, instead of 64-bit serial numbers containing unique, positive integers with 64 bits of entropy.
Why is a CRL 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 may 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 may access a potentially risky site, leaving them vulnerable to:
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 in real time.
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.
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 may lead to a denial-of-service (DoS) attack.
Another issue is the risk of other security vulnerabilities because different browsers handle CRLs differently. 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.
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. Nonetheless, they will still allow the connection to go ahead without a warning.
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 actually 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.
OCSP is an alternative to using CRLs. Instead of having to download the latest CRL and check whether a requested Uniform Resource Locator, or URL, 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.
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.
More on Digital Certificates Here