What is a Certificate Revocation List?
A certificate revocation list, more commonly called a CRL, is exactly what it sounds like: a list of digital certificates that have been revoked.
A CRL is an important component of a public key infrastructure (PKI), a system designed to identify and authenticate users to a shared resource like a Wi-Fi network. The CRL is populated by a certificate authority (CA), another part of the PKI. Importantly, only the CA that issued the certificate has the power to revoke it and place it on the CRL.
Why is a Certificate Revocation List Necessary?
Without a CRL, there’s no way for the PKI to know whether a certificate has been revoked before its expiration. The PKI already has a list of authorized users (and their assigned certificates), but it needs a list of unauthorized users too.
Also, a CRL is necessary because there’s a difference between certificate revocation and certificate expiration.
Certificate expiration is what occurs at the end of the predetermined certificate lifecycle. When generated, a key property imparted on the certificate is how long the certificate will remain valid for – typically between 1 and 5 years. At the end of that duration, the certificate expires and becomes invalid automatically.
Certificate revocation is a (usually manual) process in which a certificate is deemed invalid before the end of its lifecycle. It can be due to any number of reasons (which will be covered later in this article), but it’s important that the PKI knows to immediately stop authenticating the certificate from then on.
A certificate that expires does not go onto the CRL because an expired certificate is automatically rejected by the operating system, or if it were to pass through, the RADIUS Server (or AAA Server) would also reject it. An expired certificate is rejected at the first step of the authentication process, well before the CRL is checked, so there’s no need to include it there.
Furthermore, certificates that reach their expiration date while on a CRL are automatically removed from the list. Regardless of the reason for their revocation, they won’t be authenticated anymore anyway. This procedure also serves the purpose of reducing the CRL list size, which can slow down authentication time if it becomes too big.
How do Certificate Revocation Lists Work?
The certificate revocation list check occurs at a specific point in the authentication process. Here’s a brief summary of how certificate authentication works for a typical WPA2-Enterprise network with EAP-TLS authentication protocol (which is the typical environment in which you encounter a PKI with a CRL).
- A user requests access to the network through the access point and submits their digital certificate for authentication.
- The access point sends the certificate to the RADIUS server, which checks if it is expired or not.
- If it’s still valid, the RADIUS checks the directory (such as Active Directory) of approved users.
- If the user is approved, the RADIUS checks the CRL to confirm that their certificate has not been revoked.
- If all of the above are passed, the user is authenticated and permitted access to the network.
Example of a Certificate Revocation List
This is what a standard CRL looks like:
If you’d like to dig a little deeper, you can download a certificate revocation list yourself very easily. In any browser, find the padlock icon in the address bar. The presence of that padlock indicates that whatever site you’re on is secured by SSL, a type of encryption that utilizes certificates.
Clicking on that padlock will open a menu in which you can choose to view the certificate, and somewhere in that dialogue box will be a “Certificate Details” option with more information. Included is a CRL path, which has a url to the CRL that’s referenced by the issuing CA. Enter the URL to see the certificate revocation list.
There are many more certificates on your machine, including those that come native to your operating system.
Reasons that Digital Certificates are Revoked
The reason that a certificate was revoked is actually recorded in the CRL, so you can reference it when deciding whether to reissue a certificate or keep it revoked. Here are the RFC 5280 revocation codes (called Reason Codes), usually just referred to by their assigned number.
- unspecified (0)
- A catch-all code for any reason that isn’t specified. Usually the default option.
- keyCompromise (1)
- The certificate itself was compromised, specifically the private key contained in the certificate.
- cACompromise (2)
- The certificate authority that issued this certificate was compromised, which means all of the certificates it has ever issued are now compromised.
- affiliationChanged (3)
- This code is reserved for when the employee the certificate was issued to leaves the organization.
- superseded (4)
- This code indicates that the certificate was revoked because user information had to be changed, such as the legal name of the user being changed.
- cessationOfOperation (5)
- This is a simple one, it just means that the certificate was replaced.
- certificateHold (6)
- This is something of a generic code that indicates a certificate has been revoked only temporarily.
- removeFromCRL (8)
- Somewhat counterintuitively, this indicates that the certificate authority has been removed from the network, and thus, CRL.
- privilegeWithdrawn (9)
- Similar to affiliationChanged, this code is reserved for when the user of the certificate, a person or device, has had their network privileges revoked. This usually occurs when the person leaves the organization or a device is decommissioned, then their certificate is also retired.
- aACompromise (10)
- The RADIUS server handling the certificate authentication was compromised, and so any certificate that passed through may have also been compromised.
CRL Alternatives and Additions
Delta CRL
A delta CRL is an optional auxiliary CRL that only contains the changes made since the last Base CRL update. A Base CRL is the same standard CRL we’ve been talking about this whole time, it’s just called “Base” in relation to a delta CRL if one is present.
Large organizations, or ones that need to revoke certificates regularly, often have CRLs that grow to huge lengths. Since a certificate has to stay on the CRL until it reaches its natural expiry date, they may stay on the list for several years. At some point, the CRL contains so many entries that it takes the RADIUS a significant amount of time to download and check it – which impacts authentication speed.
Since no one wants to wait to connect to the internet, the delta CRL is used to speed up the process. The RADIUS stores or caches a copy of the Base CRL internally, then during authentication it only needs to request the delta CRL. The delta CRL contains any certificates revoked since the last Base CRL update and is much shorter. Every week or so the RADIUS downloads a new version of the Base CRL and the Delta CRL is emptied and refreshed.
OCSP
OCSP stands for Online Certificate Standard Protocol. It’s a protocol described in RFC 6960 that can be used to request the revocation status of a digital certificate.
OCSP is simpler and faster than CRLs because the certificate check is performed by the (usually public) CA instead of your PKI, shifting the burden to them. It also carries less data and is easier for the CA to parse. However, OCSP is significantly less secure than a full PKI with CRL for several reasons.
First, OCSP has no requirement for encryption, which is inherent in the authentication process used by a PKI. Secondly, it is less informative – the only information you can receive from an OCSP request is whether a certificate is “good”, “revoked”, or “unknown”.
But the worst flaw of OCSP is that it is vulnerable to replay attacks. A hacker can intercept a certificate’s “good” response and then replay it to another OCSP request later. Since OCSPs conserve server resources by giving their responses a validity period measured in days, they can reduce the number of necessary responses but risk being compromised in that time period.
ARL
An ARL, or Authority Revocation List, is a little-seen derivative of a normal CRL. It’s a list that contains revoked certificates that were originally distributed to certificate authorities (CAs), rather than end-users or clients.
An ARL only comes into play if you’re managing a chain of trust – multiple levels of certificate authorities, from root to intermediate CAs, meant to partition the “trust” in a way that limits the potential damage of a compromised CA.
Easy CRL Management
For the most part, a properly configured CRL runs itself. You would rarely need to interact with it directly – a good PKI solution will include a management suite that lets you revoke certificates in just a few clicks.
SecureW2 provides just such a management suite – it’s intuitive, powerful, and highly customizable to suit any organization’s needs. We have affordable PKI and CRL solutions for organizations of every size, see our pricing here.
