Need to revoke a certificate? There’s a list for that…
X.509 digital certificates are integral to public key infrastructure (PKI) and web security as a whole. But what happens when something goes wrong with one of those certificates or its keys? Any certificate can find its head on the chopping block, so to speak — or what’s better known as being added to a certificate revocation list (CRL).
We’ve seen mass certificate revocations happen before. For example, Apple, Google and GoDaddy (and a few other CAs) revoked millions of certificates last year due to the certificates having 63-bit serial numbers instead of 64-bit ones. And just earlier this year, we saw Let’s Encrypt facing a mass certificate revocation due to a bug in their code.
But what exactly is a certificate revocation and how does it work? What is a certificate revocation list? And, moreover, what role does a CRL play in website security as a whole?
Let’s hash it out.
Defining CRLs: What Is a Certificate Revocation List?
The answer to your question about what a certificate revocation list (or CRL) is depends on whom you ask. For example, the National Institute of Standards and Technology (NIST) defines a CRL as “A list of revoked public key certificates created and digitally signed by a Certification Authority.”
But it’s more than that. The more technical answer from the Internet Engineering Task Force’s (IETF) RFC 5280 describes a CRL as a time-stamped and signed data structure that a certificate authority (CA) or CRL issuer periodically issues to communicate the revocation status of affected digital certificates. Depending on the provider, certificate revocation lists are offered hourly, daily, or weekly.
But this description doesn’t quite do it justice, either. Personally, I’d prefer to define a certificate revocation list (CRL) as a blacklist of X.509 digital certificates that a CA revokes prior to their assigned expiration dates. It’s important to note, however, that this list doesn’t include expired certificates. Furthermore, in some cases, third-party entities issue and maintain CRLs on behalf of CAs. This means that the CRL issuer isn’t always the same as the CA who issued the revoked certificate.
But before we can get into the nitty-gritty details of what a certificate revocation list fully entails, we first need to address what certificate revocation is in general.
The Purpose of Certificate Revocation
Much like the name implies, certificate revocation is a process that distinguishes invalid and untrusted certificates from valid trusted ones. Basically, it’s a way for CAs (or CRL issuers) to make it known that one or more of their digital certificates is no longer trustworthy for one reason or another. When they revoke a certificate (a process that’s sometimes known as PKI certificate revocation), they essentially invalidate the cert ahead of its expiration date.
So, should a CA need revoke a certificate for your website, it makes Google Chrome display a lovely warning message like this to your site visitors:
Needless to say, it’s definitely not a good look for your business’s website. This message doesn’t exactly foster warm and happy feelings of trust in your users… nor should it.
Certificate Transparency Logs vs Certificate Revocation Lists: Aren’t They the Same?
There is sometimes confusion about whether certificate transparency (CT) logs are the same as CRLs or if they serve the same purposes. So, let me answer this question directly: No, CT logs and CRLs are not the same thing. While they both deal with X.509 digital certificates, they’re two separate processes that serve two separate functions.
Certificate transparency logs are a way for CAs to record every certificate that they issue for an individual domain. A CT log is, essentially, a certificate inventory for your domain. But this doesn’t tell you whether a certificate is revoked. CRLs, on the other hand, are about informing clients whenever they revoke a certificate. But they don’t include a list of every certificate that a CA issues for your domain.
Why Would a CA Add Certificates to a CRL?
There isn’t a one-size-fits-all answer for this question. A CA can revoke a certificate of your website for one of several reasons:
- Someone compromises (or is suspected of compromising) your certificate’s private key. (This is the most common reason.)
- The CA mis-issues a certificate and issues a new one to replace it.
- The CA itself is compromised.
- Your organizational details listed in the certificate (for example, your organization’s name) change and the CA needs to reissue the cert to reflect that change.
- A certificate is illegitimate or was fraudulently signed with a stolen key. (You naughty boy/girl, you.)
But just how frequently are certificates revoked? We’ll defer to the SANS Internet Storm Center (ICS) to answer that question. Here are a the most recent certificate revocation statistics for the last month and last year:
Why a Certificate Revocation List is Necessary
When a CA issues a digital certificate, they’re expecting the certificate to be in use for its entire lifespan. (Certificates are currently valid for two years, but certificate validity will be reduced to one year — or, more specifically, 398 days — for certificates issued on or after Sept. 1, 2020.)
But not all certificates survive that full time. They sometimes get revoked early, and that’s when they join CRLs. This is different from the process for expired certificates, which CAs invalidate and browsers and operating systems reject automatically. (Hence why they aren’t added to certificate revocation lists.)
As you can imagine, a certificate revocation causes a lot of problems if clients don’t know that a particular cert is revoked. (The “your connection is not private” warning message you saw earlier is the perfect example of one of those issues.) So, to make certificate revocations easier to track, CAs (and CRL issuers) add them to their CRLs.
What’s Included in a Certificate Revocation List
A certificate revocation list is a list of untrustworthy X.509 digital certificates. While SSL/TLS certificates, or what are known as website security certificates, are the most common, CRLs can also include code signing certificates and, I believe, email signing certificates (or what are known as S/MIME certificates).
Basically, these are certificates that trusted CAs revoke before their official expiry dates.
But what kind of information can a certificate revocation list include? A CRL entry may include any of the following:
- The certificate’s serial number.
- The certificate’s signature algorithm.
- The common name (CN).
- The certificate’s extension(s).
- The revocation date and time.
- The name of the CRL issuer.
- The date by which the next CRL will generate.
Here’s an example of a Sectigo (formerly Comodo CA) CRL:
It’s important to note that once a certificate is added to the list, it’s basically a permanent fixture, according to the IETF RFC 5280:
“An entry is added to the CRL as part of the next update following notification of revocation. An entry MUST NOT be removed from the CRL until it appears on one regularly scheduled CRL issued beyond the revoked certificate’s validity period.”
How a Certificate Revocation Status Check Works
There are plenty of free online tools you can use to check your certificate’s revocation status. For example, there’s certificate.revocationcheck.com. When I type in the URL of The SSL Store, this is what it shows:
But how does the certificate revocation check process work for clients and web servers? Let’s use the SSL/TLS certificate on this website as an example.
Before your web browser (client) establishes a secure, encrypted connection to TheSSLStore.com, your client first needs to know whether the server it’s connecting to is legitimate. The way it does this is by checking our SSL/TLS certificate.
But how does your client know whether the certificate our server provides is valid? After all, for all your client knows, we’re a fraudulent website that’s pretending to be The SSL Store and this is an imposter site. (Of course, to do this, it means that a cybercriminal compromises a website or web service’s certificate or private key, or if a certificate is improperly issued for one reason or another [which is far less likely], then the CA must revoke it.)
So, how does the client know whether a certificate is valid or has been revoked? There are two ways the client can do this:
- It manually checks the certificate revocation list for the certificate in question.
- It sends an OCSP request to an OCSP responder to check the revocation status for the specific certificate via the CA’s revocation server.
How the Client Checks the CRL and OCSP
In these two methods, the onus for checking the certificate revocation status falls on the client. Basically, the client is responsible for checking whether a certificate is revoked before connecting to it.
Certificate Revocation List-Based Certificate Revocation Status Check
To check the status of a certificate using a CRL, the client reaches out to the CA (or CRL issuer) and downloads its certificate revocation list. After doing this, it then must search through the entire list for that individual certificate. This is not only cumbersome but it’s also slow. To speed up performance, the client may only download updated CRLs every 24 hours or so.
OCSP-Based Certificate Revocation Status Check
In the second status check method, the client sends an OCSP request to the OCSP responder to check the real-time status of a certificate. The OCSP responder then sends back one of three certificate status responses — good, revoked, or unknown — and the client can then react accordingly.
Advantages and Drawbacks of Client-Based Certificate Revocation Status Checks
The advantage of OCSP is that it’s faster than the traditional CRL-checking process and also provides more up-to-date information about a certificate’s revocation status. But there are cases in which a CRL might be more beneficial (mainly when an OCSP server goes down — even just temporarily.)
However, there are drawbacks to both:
- CRL lists grow and CAs release new lists. Since CRL-based verification methods require certificate revocation status checks for every connection, there’s a chance that the CRL issuer or CA may release a new list and you’ll miss out on newly revoked certificates. This isn’t good for scalability.
- These two methods are resource-intensive for the client. They suck up a lot of resources and increase latency as well. This leads to a crappier user experience. After all, there are a lot of certificates the client must slog through on that list every time.
- Your privacy protection funnel has a few leaks. Your secure website usage isn’t as secure as you may think when you use OCSP. Why? Because the browser tells the CA servers who is accessing which websites. So, if you don’t want anyone (including the CA) to know about your secret penchant for collectable figurines or love of cat videos, then user beware.
- CRLs and OCSPs are dependent on a CA’s infrastructure. If you’re using an unreliable CA that has a lot of server downtime or availability issues, this can make relying on both of these practices a lot more troublesome.
A major red flag, though, comes in the form of browsers’ CRL check soft fail policies. What I mean by this is that when a client checks the CRL list, or they send a message to the OCSP responder and get an “unknown” response, some browsers may assume that the certificate is valid and allow the connection regardless of the potential danger.
Enter OCSP Stapling
There is a third option, though, which is a web server-based certificate revocation status check that’s known as OCSP stapling. OCSP stapling puts the responsibility of performing OCSP requests on the web server instead of the end user’s client. This is a less resource-intensive process and unburdens the client, which provides a more seamless experience for the end user. It also avoids the data leakage concerns that the client-based OCSP status check method experiences.
Essentially, it’s the new-and-improved implementation of traditional OCSP.
Basically, with OCSP stapling, the web server is in constant communication with the CA’s revocation server. It timestamps and caches the most recent OCSP responses so that it can “staple” (attach) it to clients’ SSL/TLS handshake request responses. This helps to ensure coverage during short CA server outages.
However, there’s a lot more to know about OCSP stapling. So, I’ll discuss OCSP stapling — and the online certificate status protocol in general — more later this week in another article next week, so stay tuned for that. (Insert a shameless “subscribe now to our blog” message.)
Wrapping Up the Topic of Certificate Revocation Lists
As you can see, there’s a lot to know about certificate revocation lists. They’re like the cybersecurity equivalent of Santa’s “Naughty and Nice” list — you know who is being good (because they use valid X.509 certificates) and who deserves coal in their stocking (because they aren’t).
CRLs are useful for helping your client determine whether or not it’s safe to connect to a web server. However, they’re not perfect:
- Certificate revocation lists are clunky, slow, and burdensome for clients to continually download and sort through.
- Whether your client downloads a CRL list to check each individual certificate or it relies on an OCSP responder to provide a real time certificate status check of the revocation server, there’s still a chance that something can go wrong and you wind up relying on old data.
- OCSP stapling is a better option that reduces latency and puts the responsibility of CRL revocation checks on web servers (instead of clients).
I hope this article provides clarity about certificate revocation lists and illuminates the certificate revocation status checking process for you.
As always, feel free to drop a comment to share your thoughts and insights.