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 1st, 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)
What is a Certificate Revocation List (CRL)?
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 CAs 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 RFC 5280. 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.
How web browsers and applications check CRLs
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
What is a CRL Distribution Point (CDP)?
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.
Why are CRLs important?
- The CA discovers it has improperly and wrongfully issued a certificate
- A certificate is believed or is discovered to be fraudulent
- A certificate’s private key has been compromised
- The issuing CA has been compromised
- The web site owner ceases doing business and no longer owns the domain name or the server defined in the certificate
- During the web site authentication and validation the requester misrepresents some information used in the process, or the web site owner has violated the terms of its agreement with the CA
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:
- Data breaches of personal or sensitive information. An attacker performing a man-in-the-middle attack may be able to intercept personal and sensitive the user enters on a web server. This information might be Social Security Numbers, bank account information, credit card numbers, medical data, etc.
- Identity theft and impersonation. A bad actor might be able to capture the identity credentials the user inserts to authenticate themselves on a web server. Credential theft and compromise is a key reason for impersonation attacks or business email compromise (BEC) campaigns. In addition, criminals might use these credentials to hijack the user’s account.
- Financial loss. With banking, credit card, and credential information stolen, the cybercriminal is only a step away from stealing the user’s money.
- Installation of malware. Accessing an insecure website is a way for criminals to install malware on the victim’s computer. This malware is then used to steal personal information, run keyloggers, or hijack the computer to be part of a bigger DDoS attack. Installing malware can also be financially motivated using a ransomware variant and encrypting all data in the user’s computer.
Considerations with using CRLs
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.
OCSP & OCSP Stapling
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:
- Improved performance, as the browser receives the status of the server certificate when it is needed, avoid the overhead of communicating with the issuing CA.
- Improved security, by minimizing the instances of false positives and reducing the number of attack vectors.
- Enhanced user privacy, since the CAs get requests only from websites and not from users.
Why CRL and OCSP monitoring is critical
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).
It's all about efficient certificate lifecycle management
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.