Certificate revocation is an important, and often overlooked, function of certificate lifecycle management. In this blog, we’ll explore key functions of certificate revocation, including certificate revocation lists (CRLs), Online Certificate Status Protocol (OCSP) and OCSP stapling.
Digital certificates are used to create trust in online transactions. The dual role of the certificates – to encrypt communications and to authenticate the identity of the certificate owner – forms the foundation of the Public Key Infrastructure (PKI).
Every certificate also has a finite validity period, which as of September 1 st , 2020 is set to 13 months. However, during that validity period, a certificate owner and/or certificate authority (CA) that issued the certificate may declare it is no longer trusted. In these unfortunate cases, the untrusted certificates need to be revoked and users need to be informed. This is done by adding the untrusted TLS/SSL certificate to a Certificate Revocation List (CRL).
Here is an example of a revoked SSL/TLS certificate warning in Google Chrome (Image Source)
Certificate revocation is a critically important component of the certificate lifecycle. There are many definitions to what a CRL is, but if we break it down simply, a CRL contains a list of revoked certificates – essentially, all certificates that have been revoked by the CA or owner and should no longer be trusted.
The CA Security Council defines a CRL as “a digitally-signed file containing a list of certificates that have been revoked and have not yet expired.” The digital signature of the CRL files by the issuing CAs is important to prove the authenticity of the file and to prevent tampering.
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 a CA’s internal policies, CRLs are published on a regular periodic basis which might be hourly, daily, or weekly. The status of a certificate in the CRL can be either “revoked,” when it has been irreversibly revoked, or “hold” when it is temporarily invalid.
The format of a CRL is defined in the X.509 standard and in RFC5280. Each entry in a Certificate Revocation List includes the identity of the revoked certificate and the revocation date. Optional information includes a time limit, if the revocation applies for a specific time period, and a reason for the revocation.
Certificates contain one or more URLs from which the browser or application can retrieve the CRL response. When a browser initiates a TLS connection to a site, the server’s digital certificate is validated and checked for anomalies or problems.
During this validation process, the web browser checks if the certificate is listed in the CRL issued by the corresponding CA. Depending on the status of the server’s certificate, the browser will either create a secure connection or alert the user about the revoked certificate and the risk of continuing with an unencrypted session.
Checking the CRLs is an essential step in a PKI-based transaction because they verify the identity of the site owner and discover whether the associated certificate is trustworthy.
Here is an illustrated workflow of the certificate revocation check process using CRL
When an application or browser checks for certificate revocation status, it retrieves the current CRL from a specified CRL distribution point (CDP). A CDP is the location on an LDAP directory server or web server where a CA publishes CRLs.
After the CRL is retrieved, it’s typically cached until the CRL itself expires. The CDP must be reachable at all times to ensure that devices or applications can retrieve the new CRL when needed. Otherwise, it is not possible to determine the status of the certificate in question, and the certificate revocation status checks will fail.
Digital certificates are revoked for many reasons and there are many recent examples of mass certificate revocations. Reasons for certificate revocation include the following:
Whatever the reason might be for a certificate to be revoked, CRLs are important for protecting users from man-in-the-middle attacks or communicating with a fraudulent site which impersonates a legitimate one. Without the CRLs, users would be faced with numerous security and privacy risks, such as:
Despite the importance of maintaining a current CRL, the process is not flawless. Even though each CA issues a separate CRL, the file can become quite large, making them inefficient for use in devices with limited memory, like smartphones or IoT devices.
When a CA receives a CRL request from a browser, it returns the whole file with the revoked certificates from that CA. The browser must then parse the list to determine if the requested certificate has been revoked or not. Depending on the size of the file, the process might result in latency and poor performance for web users.
Another problem is that if the client does not have a “suitably recent” copy of the CRL, it has to fetch one during the initial connection to the site which can make the connection last longer.
The truth is maintaining CRLs is not appropriate for releasing and distributing critical information in near-real time. Since browsers are caching CRLs to avoid computational overhead, a time window might occur where a revoked certificate might be accepted creating privacy and security risks for the users.
Another method used to convey information to users about revoked certificates is the Online Certificate Status Protocol (OCSP). Instead of downloading the latest CRL and parsing it to check whether a requested certificate on the list, the browser requests the status for a particular certificate from the issuing CA’s revocation server.
Using the certificate’s serial number, the OCSP service checks for certificate status, then the CA replies with a digitally signed response containing the certificate status. An OCSP response contains one of three values: “good”, “revoked”, or “unknown”. OCSP responses are smaller than CRL files and are suitable for devices with limited memory.
Here is an illustrated workflow of the certificate revocation check process using OCSP
OCSP stapling is an enhancement to the standard OCSP protocol and is defined in RFC 6066. Enabling OCSP stapling eliminates the need for a browser to send OCSP requests directly to the CA. Instead, the web server caches the OSCP response from the CA and when a TLS handshake is initiated by the client, the web server “staples” the OSCP response to the certificate it sends to the browser.
Here is an illustrated workflow of the certificate revocation check process using OCSP Stapling
OCSP stapling presents several advantages including:
If a CA is down, you’ll be unable to issue new certificates, but if your CRL is expired or unreachable, all of your certificates become immediately unusable. As discussed, most applications need to check the validity of certificates against a CRL or OCSP server. If they cannot reach the CDP or OCSP responder, or if the CRL itself is expired, users won’t be able to access their application.
Real-time and continuous revocation monitoring provided by certificate lifecycle automation tools like Keyfactor Command can ensure that this doesn’t happen (see video below).
Effective and efficient revocation of rogue, compromised, or untrusted certificates enforces the security and privacy of millions of online transactions every day. Organizations need to automate and centrally manage their digital certificates to avoid costly outages or attacks because of certificate revocation or expiration.
Keyfactor Command allows you to manage the lifecycle of keys and digital certificates across your business and gain visibility from certificate discovery and monitoring to issuance, renewal, and revocation. Watch our on-demand demos to learn more about our end-to-end PKI and certificate lifecycle automation platform.
Keyfactor’s identity-first security newsletter
Get helpful resources and insightful perspectives from cybersecurity leaders delivered to your inbox every month.
