X.509 digital certificates are the cornerstone of Public Key Infrastructure (PKI), securing billions of online transactions. But what happens when something goes wrong with these certificates or their associated keys? It is obvious they can no longer be trusted, and they have to be revoked. To let users be aware that a certificate has been revoked, it has to be added to a certificate revocation list (CRL).
In recent PKI history, we have witnessed mass certificate revocations happen before. For example, in 2019 Apple, Google and GoDaddy revoked millions of certificates due to the certificates having 63-bit serial numbers instead of 64-bit ones. And in March 2020, Let’s Encrypt performed a mass certificate revocation due to a bug in their code.
CIO Study: Outages Escalating with Massive Growth in Machine Identities
What is a Certificate Revocation List?
A Certificate Revocation List (CRL) is a crucial component in the world of digital security. It is essentially a blacklist of digital certificates that have been revoked by the issuing Certificate Authority (CA) before their designated expiration date. CRLs serve as a means to enhance trust and security by providing browsers and systems with a list of certificates that should no longer be trusted. Browsers use CRLs to verify the validity and trustworthiness of a certificate before establishing a secure connection. According to the National Institute of Standards and Technology (NIST), a CRL is defined as 'a list of revoked public-key certificates created and digitally signed by a Certification Authority.' By regularly checking CRLs, systems can ensure the integrity of digital certificates and maintain a secure online environment.
The Internet Engineering Task Force’s (IETF) RFC 5280 provides a more technical definition, describing 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.
What Does a Certificate Revocation List Include?
While CRL’s may vary, the following are a few things that are commonly included:
- CRL issuer name
- Certificate’s extension(s)
- The CN or the common name
- Date when the next CRL will be issued
- Signature algorithm of certificate
- Serial number of certificate
What is a CRL Distribution Point (CDP)?
The CRL Distribution Point or CDP is a X.509 v3 certificate extension that pinpoints the location of the CRL.
Why is a Certificate Revocation List Necessary?
The PKI already has a list of authorized users, but it also needs a list of unauthorized users. Without a CRL, there is no way for the PKI to know whether a certificate has been revoked or not.
CRLs are a way for CAs to announce that one or more of their digital certificates is no longer trustworthy for a certain reason. When CAs revoke a certificate, they essentially invalidate the certification ahead of its expiration date. In addition, 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. At the end of that timeframe, the certificate expires and becomes invalid automatically. Certificate revocation is a process in which a certificate is invalidated before the end of its lifecycle. The invalidation can be due to a number of reasons, but it is important for the PKI to immediately stop authenticating the certificate.
Why Are Certificates Revoked?
Certificates are revoked for many reasons that are recorded in the CRL. In addition, RFC 5280 provides an extensive list of revocation codes. The most common ones are the following:
- The certificate’s private key is compromised
- The CA mis-issues a certificate and issues a new one to replace it.
- The CA itself is compromised.
- The organizational details listed in the certificate change and the CA needs to reissue the certificate to reflect that change.
- A certificate is illegitimate or was fraudulently signed with a stolen key.
The importance of the CRLs can be understood if we have a look at the frequency certificates are revoked. The SANS Internet Storm Center (ICS) can help us understand the magnitude of the problem. The illustrations below depict the most recent certificate revocation statistics for the last month and last year:
Figure 1: Certificates revoked in August 2020. Source: SANS Internet Storm Center
Figure 2: Certificates revoked between September 2019 and August 2020. Source: SANS Internet Storm Center
How Browsers Check for Revoked Certificates?
Before browsers establish a secure, encrypted connection to (for example) venafi.com, they check whether the server they are connecting to is legitimate. They do that by checking the SSL/TLS certificate. There are two ways a browser can do this:
- Check manually the CRL for the certificate in question. The client reaches out to the CA and downloads its certificate revocation list. Then, it must search through the entire list for that individual certificate. This process is cumbersome and slow. To increase performance, the client downloads updated CRLs every 24 hours.
- Send an OCSP request to an OCSP responder to check the revocation status for the specific certificate via the CA’s revocation server. The OCSP responder then sends back one of three CRL status responses—good, revoked, or unknown—and the client can then react accordingly.
A short note on OCSP. OCSP stands for Online Certificate Standard Protocol. It is 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 CA instead of your PKI, shifting the burden to them. It also carries less data and is easier for the CA to parse.
Drawbacks of Client-Based Certificate Revocation Status Checks
In the two methods described before, the burden for checking the certificate revocation status falls on the client (browser). It is the browser that is responsible for checking whether a certificate is revoked before connecting to it.
In addition to making browsers responsible for checking the status of the certificates, there are other drawbacks as well:
- CRL lists grow and CAs release new lists daily. Since CRL-based verification methods require certificate revocation status checks for every connection, the browser might not possess the latest CRL.
- Both methods are resource-intensive for the client. They consume a lot of resources and increase latency as well.
- OCSP presents security and privacy concerns, since it has no requirement for encryption and is vulnerable to replay attacks.
- CRLs and OCSPs are dependent on a CA’s infrastructure. Relying on a CA with availability issues makes the reliability of both practices questionable.
OCSP stapling
Because of these drawbacks, the industry has developed a third option, which is a web server-based certificate revocation status check, known as OCSP stapling. OCSP stapling puts the responsibility of performing OCSP requests on the web server instead of the user’s client. This is a less resource-intensive process, 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.
Conclusion
Certificate Revocation Lists are very important for placing trust on online communications and transactions. However, they present many challenges, some of them were discussed in this post. Maintaining a robust certificate management program is the best way to mitigate these challenges. Venafi’s TLS Protect machine identity security solution can help you secure your TLS certificates infrastructure.