In 2014, Mozilla moved away from using certificate revocation lists (CRLs) to check the validity of TLS certificates with the release of Firefox 28.0. So, do CRLs still matter? Yes, they do – here’s why they are still used by many certificate authorities and browsers, including Google Chrome.
Staying safe online is a big issue, and internet users are increasingly expecting to be assured that their online activity is secure. SSL / TLS certificates are a valuable tool, giving us important details about the status of websites and helping us to secure our networks and private data from the prying eyes of cybercriminals – but they become useless if they are invalid.
TLS certificates can become invalidated typically in one of two ways – certificate expiration and revocation. The TLS certificates can become invalidated typically in one of two ways – expiration and revocation. The certificate clearly mentions the expiration date, and browsers generally will not connect to a website with an expired certificate. But what if the certificate is revoked before its assigned expiration date? Browsers have a few different ways of dealing with this, including checking a CA’s certificate revocation list (CRL), their online certificate status protocol (OCSP) responses, and the related process known as OCSP stapling.
In future articles, we’ll look at OCSP and OCSP stapling more in depth. But for now, we’ll focus on learning and exploring everything “CRL” in this article.
What Is a Certificate Revocation List? CRLs Defined and Explained
A certificate revocation list is an indelible list of websites that have been revoked by the certificate authorities (CAs) that issued them prior to their assigned expiration dates. Basically, it’s a list of certificates that’s continuously updated to warn browsers and operating systems that something is wrong and that they should avoid visiting those websites because they are not secure.
Once a certificate is added to the list, it can never be removed. The whole point is for the list to serve as a permanent record.
Let’s take a quick peek at what a CRL looks like. We’ll use Sectigo’s certificate revocation list (CRL) as an example:
Still feeling a bit unclear on all of this? Think of a certificate revocation list as something akin to US recalls.gov website. This site contains lists of various categories of products that have been recalled by manufacturers due to safety, health, or other critical concerns. Basically, this list informs you that there’s something wrong with specific items and that you should avoid using them.
Like products listed on the government recall list, websites on the CA’s list of revoked certificates are not trustworthy. Certificate authorities release their CRLs containing details about revoked certificates at regular intervals, which vary based on each individual CA’s policies. Once a certificate is revoked, it will always remain on the CRL.
Based on the information contained in the CRL, if a website certificate is valid, the browser will allow the connection. If the certificate is revoked, the browser will show a warning similar to this:
What Information Does a CRL Contain?
A CRL can contain a lot of information:
- CRL issue date and date of next update
- Certificate issuer names
- The cryptographic digital signature algorithm used to digitally sign the CRL
- The serial numbers of the revoked certificates
- Revocation date and time
- Reason for each certificate’s revocation (optional)
However, most certificate revocation entries typically just include the serial number and revocation date.
The following screenshots show the CRL generated and published by Adobe CA. You can see that there are two boxes in the first screenshot. The first shows the basic information, the second box shows more details.
There are three boxes in the second screenshot. The first provides an overview of all the revoked certificates the CA has and the corresponding date and time each was revoked. If you click on a particular serial number, you will see more details for that individual certificate displaying in the second box. The third box shows additional information about the certificate or the reason why it was revoked.
Why Do TLS Certificates Get Revoked?
A CA can revoke a TLS certificate for one of several reasons and the reason is recorded in the CRL with a code. In the screenshot above, we can see that the CRL reason code is ‘Superseded (4).’ But what are these codes and what do they mean?
Let’s take a quick peek at the certificate revocation reason codes listed in the IETF’s RFC 5280 and what they mean:
- Unspecified (0) – Any other reason.
- KeyCompromise (1) – A private key is compromised.
- CACompromise (2) – The CA is compromised.
- AffiliationChanged (3) – The certificate owner is no longer with the organization.
- Superseded (4) – Another certificate supersedes the present certificate.
- CessationOfOperation (5) – The organization has ceased normal operations and the certificate has been replaced.
- CertificateHold (6) – If the certificate has been revoked temporarily.
- RemoveFromCRL (8) – A CA has been removed from the network.
- PrivilegeWithdrawn (9) – The privileges contained within the certificate have been withdrawn.
- AACompromise (10) – The RADIUS server is compromised so associated certificates cannot be trusted.
Note: Did you notice that there’s no number seven on the list above? Good catch. RFC 5280 does not specify why the number seven is not used. All we know is that it was not included.
How Does CRL Verification Work?
CRL verification is the simplest way to verify the revocation status of TLS certificates. The figure below explains the process:
As you can see, CRL verification is carried out by the client browser.
- First, the browser sends a connection request to the server.
- Then, the server sends its certificate to the client.
- The client might have already downloaded and cached the CRL. If it has not downloaded the CRL beforehand, it sends a request to the CA or the CRL issuer to get a copy of the list from its server.
- Once the client receives the CRL, it can check the list to see if the server certificate is revoked.
- If the client does not see the certificate in the revocation list, it assumes that the certificate is valid and connects to the website.
- If the browser finds the website certificate on the list, it means that it has been revoked and the website is no longer trustworthy. In this case, you will see a warning message (like the example you saw earlier) and the browser will end the connection.
Advantages of CRL Verification
The online certificate status protocol (OCSP) is another way to verify the status of TLS certificates online. In the OCSP verification process, the status of a particular certificate is requested (whether it is good or not). With a CRL, the list of all the revoked certificates is requested and then the browser confirms that the particular site’s TLS certificate is not on list (meaning, it’s thought to still be valid and has not been revoked early).
When we compare CRL verification with OCSP, OCSP is the clear winner in terms of efficiency and security. Still, the CRL method does have a couple of things going for it:
- It is faster and more efficient than OCSP in situations where the client browser has to verify the revocation status of multiple certificates. The browser can download a single CRL and then compare multiple serial numbers against it. It does not need to send a request the status of individual certificates every time it needs to confirm.
- It still works during network outages as the list is stored locally once downloaded. This differs from when the OCSP server is down – in this situation, the OCSP verification will fail.
Disadvantages of CRL Verification
CRLs have several disadvantages compared to OCSP, including:
Taxing on Network Resources
CRL verification takes up more network resources as the browser must download the whole list of revoked certificates, then parse the list for the certificate of the site it is attempting to access. This process is also more time-consuming than with OCSP.
No Real-Time Updates
Unlike OCSP, CRLs do not offer real-time results as they are updated hourly, daily, or weekly. So, there is always a chance that a CRL could be outdated and the website it is trying to connect to has its certificate revoked since the last update.
CRLs Require a Good CA Infrastructure
If the certificate authority that issues the certificate revocation list does not have a strong, reliable infrastructure, then you’re going to run into trouble. If the CA experiences a lot of downtime and other availability-related issues, it makes it hard to get a hold of the CRL. However, the same can also be said about the OCSP server responses as well.
(This is where OCSP stapling can help – but that’s a whole other topic that we are not going to get into here. Be sure to check back over the next few weeks for our upcoming article on OCSP stapling.
How to Check a Certificate’s Revocation Status
Many sites offer free tools to check the revocation status of websites. Let’s see what happens if we try it for SectigoStore.com using a tool on certificate.revocationcheck.com:
As you can see, the certificate is valid. This particular CRL is updated once a week by the certificate’s issuing CA (Sectigo) and lists 1,295 revoked certificates (at the time this article was written). Does this sound like a high number? Just remember that this list is a permanent list, so it’s no surprise that a CA that’s been around since 1998 would have revoked certificates.)
Image caption: A screenshot of the certificate revocation list information for Sectigo.
Final Thoughts on Certificate Revocation Lists or CRLs
A certificate revocation list contains information about all the websites with certified revoked by the CA before their expiration date. The CA generates and issues the CRLs at intervals from once per hour to once a week. CRLs have played an important role in keeping us secure online since their introduction, but due to their cumbersome nature and the issues we mentioned earlier, the internet community is moving towards OCSP and OCSP stapling.
