Certificate revocation refers to revoking a digital certificate before its expiration date. For example, revoking an SSL/TLS certificate makes it untrustworthy.
Here’s what you need to know about certificate revocation, when it may be necessary, how it is performed, and more.
Certificate Revocation Security Assessment Level
CVSS Vector: AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N
What is a Certificate Revocation?
The revocation of an SSL/TLS certificate is the process of a Certificate Authority (CA) revoking a certificate it has issued. When a website’s certificate has been revoked, it signals browsers that it may have a problem. Browsers will display warning messages to visitors of websites whose certificates cannot be trusted. In some cases, they may even block access to these websites.
Reasons for certificates to be revoked include the following:
- The domain for which a certificate has been issued no longer exists, the domain is not operational or does not belong to the original certificate owner anymore
- The certificate’s private keys show signs of having been compromised, making it insecure
- A certificate in question has been issued improperly by a CA and must be reissued
- A certificate is found to be counterfeit
- The Certificate Authority that has issued the certificate is compromised, and by extension – all of the certificates that are part of its chain of trust.
- The original certificate has been replaced with another certificate from a different CA.
If a certificate is revoked, it becomes part of a Certificate Revocation List (CRL). The reason for the certificate’s revocation is usually recorded in the CRL using a specific code. The above reasons are included in these codes, called the RFC 5280 revocation codes (also known as Reason Codes)
Certificate revocation is an important process that helps maintain greater security online. It is, therefore, quite common for certificates to be revoked because of technical issues or when they have been compromised.
Who can revoke certificates?
The certificate revocation process is usually handled by the CA that issued the certificate. The whole point of the revocation process is to say that a certificate or its holder is not trustworthy anymore, so by definition, the revocation decision-making process cannot be in the hands of the certificate holder. This is so because a certificate holder may abuse their certificate, or attackers may compromise their certificate. In either case, a third party, the CA, must make the ultimate revocation decision.
There are different levels of requesting a certificate to be revoked, depending on the type of the certificate. For a server certificate, for example, signing the revocation request with the server’s private key may be enough. However, for higher-level certificates, the process is significantly more complicated and costly. The complexity of revoking such certificates is necessary to avoid having attackers revoke certificates as a denial-of-service attack, for example.
Certificate Revocation List (CRL)
A CRL is a list that features all the digital certificates revoked, before the end of their validity period (i.e., their expiration date), by the CA that has issued them. I.e., expired certificates are not part of this list, only temporarily or completely revoked ones. When a client connects to a website, part of the process includes checking the website’s certificate for problems, including whether it is on a CRL.
Certificates on the list are either revoked or are “on hold,” i.e., temporarily invalid. If a certificate is on hold, this is reversible as long as its security and integrity can be proven. For example, this can occur when there is doubt about whether a private key has been lost. If it is found and nobody has undoubtedly had access to it, the certificate is removed from the list. Revocation, on the other hand, is irreversible.
CRLs are published periodically, at specific intervals, and have a defined period during which they are valid – often, 24 hours or less. Sometimes they are published immediately after a certificate has been revoked.
The list itself does not need to be issued by the CA. Third parties sometimes issue and maintain CRLs in lieu of the CA. So while a certificate is permanently revoked by the CA who issued it, the CRL isn’t necessarily issued by the CA. The CRL file, however, is signed by the CA to prevent tampering and interference.
In essence, the CRL is a blacklist or blocklist of X.509 digital certificates that should no longer be trusted. These lists are critical because there would be significant holes in online security without them. For example, if clients did not check CRLs when connecting to servers, this would create possibilities for man-in-the-middle attacks that can lead to data theft, account hijacks, identity fraud, the spread of malware, and more.
CRLs are not without their drawbacks, so several other solutions have been developed.
Online Certificate Status Protocol (OCSP)
Due to CRLs work, a client must parse the whole list to check for a certificate. This takes time and requires a lot of bandwidth. Sometimes, a certificate could be revoked within the time it takes for a client to check a CRL – i.e., between checking the cached CRL and downloading the updated one. This can create vulnerabilities because a revoked certificate could be accepted.
An alternative to a CRL is a more recent method called the Online Certificate Status Protocol (OCSP), also known as an OCSP responder. Using OCSP, a client will send the certificate it wants to check to the CA, which will then return a “good,” “revoked,” or “unknown” response. This reduces the overhead, compared to the CRL method, and allows for real-time certificate checking, as well as for a greater volume of checks. I.e., the OCSP method shifts the burden to the CA.
“OCSP stapling” takes this further by removing the client’s request. Instead, a website that receives a connection request from a client will attach its OCSP response along with its certificate.
Prevention Guide
Learn how to detect and prevent different kinds of SSL/TLS vulnerabilities.
How to apply for and check certificate revocation
You can most commonly request your website certificate to be revoked from the website’s administrative console. Some tools can be used for certificate management that allows for certificate revocation requests to be made, such as an Automatic Certificate Management Environment (ACME) client, and others.
When revoking your certificate, you will need to specify the reason for the request – i.e., the “reason code.” For example, if the certificate’s private key has been compromised, this would be keyCompromise (RFC 5280 CRLReason #1).
Once you have submitted the revocation request, the status of your certificate will be displayed in your certificate utility tool, and you will know when it is revoked. If the status is unknown when you check, you will likely be provided with an option to check the CAs CRL or make an OCSP request.
To make sure your certificates can be adequately revoked, use one of the following setup guides below:
Enable OCSP
Unfortunately, you cannot enable OCSP solely on your own. Your certificate authority must operate the OCSP server and store the certificate information there. If your CA does not offer OCSP, think of switching to a CA that supports this feature. If your CA supports OCSP, follow these guides to create a certificate with OCSP enabled.
OCSP Stapling
OCSP stapling is an addition to OSCP, where the webserver retrieves the OCSP answer from the OCSP server, which contains a signed timestamp. This answer is sent to the client on the original request. Therefore the client does not need to send an additional request to the OCSP server. This increases the users’ privacy as the CA does not get requests from your users accessing your web application.
Let’s Encrypt
With Let’s Encrypt, it is straightforward to enable OCSP stapling. When creating a new certificate, just add the –staple-ocsp flag. If your certificates are already generated by Let’s Encrypt, just run the same command and choose “Attempt to reinstall this existing certificate” as the first option. This will reuse your certificate and enable OCSP stapling.
certbot run -d [DOMAIN] --staple-ocsp --hstsApache
On Apache, you need to get the full certificate chain from your certificate authority and store them in the file/etc/ssl/ca-certs.pem. Then update your SSL configuration to include the SSLStaplingCache, SSLCACertificateFileandSSLUseStapling directives:
<IfModule mod_ssl.c>
SSLStaplingCache shmcb:/tmp/stapling_cache(128000)
<VirtualHost *:443>
Header always set Strict-Transport-Security "max-age=31536000"
ServerAdmin webmaster@localhost
ServerName example.com
DocumentRoot /var/www
SSLEngine on
SSLCertificateFile /etc/apache2/ssl/example.com/apache.crt
SSLCertificateKeyFile /etc/apache2/ssl/example.com/apache.key
SSLCACertificateFile /etc/ssl/ca-certs.pem
SSLUseStapling on
</VirtualHost>
</IfModule>Nginx
On Nginx, you need to get the full certificate chain from your certificate authority and store them in the file /etc/ssl/ca-certs.pem. Then update your SSL configuration to include the ssl_stapling, ssl_stapling_verify, and ssl_trusted_certificate directives:
server {
add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; ";
listen 443;
server_name example.org;
root /usr/share/nginx/www;
index index.html index.htm;
ssl on;
ssl_certificate /etc/nginx/ssl/example.org/server.crt;
ssl_certificate_key /etc/nginx/ssl/example.org/server.key;
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/ssl/private/ca-certs.pem;
}FAQs
What are the reasons for certificate revocation?
Certificates can be revoked for several reasons. Some of the most common ones include the certificate’s private key becoming compromised or the issuing CA itself becoming compromised. A certificate is also revoked when the domain it was issued for no longer exists or does not belong to the initial certificate owner.
How is an online responder different than a certificate revocation?
Unlike a CRL, an online responder, i.e., an OCSP request, only provides status information for a single certificate, whereas a CRL provides information on all revoked certificates. This is why OCSP requests are more efficient and fast, as they do not need clients to parse through the list of revoked certificates but provide the requested revocation information.
