Revoking a certificate invalidates a certificate before its scheduled expiration date. There are many reasons to revoke a certificate including, but not limited to, compromise or loss of the corresponding private key, key is no longer needed, and more. While revocation is typically discussed in the context of X.509 certificates, other certificate types such as secure shell (SSH) and pretty good privacy (PGP) (yes, we are referring to PGP public keys as certificates) also support revocation. Despite the concept of revocation having broad support, in the following paragraphs we will show how the implementations are more complicated with a lot of edge cases and overall poor support.
Methods of Certificate Revocation
The most common way to revoke a certificate is by publishing a list of revoked certificates that clients can consume. In the X.509 world this is done via a Certificate Revocation List (CRL). In this case, the Certificate Authority (CA) publishes the CRL that contains the list of certificates, the revocation state (i.e., Revoked or Hold), the reason for revocation (i.e., unspecified, keyCompromise, cACompromise, affiliationChanged, superseded, cessationOfOperation, certificateHold, removeFromCRL, privilegeWithdrawn, or aACompromise), and when the revocation took place (note: per RFC 5280 there is a difference between the Revocation Date and the Invalidity Date but Ballot CSC-12 of the CA/Browser Forum simplified this in 2021).
While CRLs work in theory, they have many problems in practice. In order for the CRL to be accessed it must be available to the client in real-time and must therefore be accessible “online”. While this isn’t usually a problem when navigating websites on the public web, it can be a problem on private networks and non transport layer security (TLS) use cases (e.g., validating signatures on code or documents on an offline machine). Additionally, if the CA is popular it may have issued a lot of certificates which can result in large CRLs which consume lots of bandwidth, negatively impact performance, and open up the possibilities of denial of service (DoS) attacks. To combat this CAs only periodically publish new CRLs and clients cache CRL results which leads to another problem – staleness of CRLs. If a certificate has been revoked it can sometimes take up to 24 hours before a client sees the updated status and by then it may be too late.
To overcome these issues, the Online Certificate Status Protocol (OCSP) was designed. OCSP allows clients to query the status of a single certificate in real-time, thereby significantly reducing the size of the data transferred and improving performance and DoS-mitigation. However, since the client queries a specific certificate at the moment it is being consumed, it leaks information to the CA about what service the client is consuming and therefore has privacy concerns. OCSP can also put a lot of burden on CAs, especially for certificates that are consumed often by many different clients (e.g., for popular websites). Protocols like OCSP with stapling have been designed to overcome this issue but never gained widespread adoption.
Fail Open vs Fail Closed
Due to the reliance on the CA infrastructure to check the revocation status, clients must decide what to do if the revocation status cannot be checked. Should the client fail open (i.e., proceed with operation such as accessing the website) or it should fail closed (i.e., don’t proceed with the operation which could mean not accessing a website or installing software)? Failing closed ties system availability to the availability of the CA infrastructure. Failing open leaves the door open for attackers to DoS the CA infrastructure so that clients don’t see that a compromised certificate was marked as revoked. Some browsers choose to fail open while some have opted to not even check the revocation status and instead rely on short-lived certificates.
Impact of a Revoked Certificate
If the client can detect that the certificate is revoked, what should it do? Some use cases are fairly obvious. For example, in a TLS case where a client is querying certificate status in real-time, a revoked certificate means that the endpoint (e.g., the server you are trying to access) should not be trusted and the TLS handshake should terminate. But what about other use cases where something was signed in the past, before the certificate was revoked? For example, software that was legitimately code signed in the past prior to its private key being compromised and certificate being revoked? Should it still pass validation? Well, if the client can verify that the signature was produced before the key compromise then yes, it should pass validation. This is why cryptographic timestamping is so important – it allows the client to reliably verify when something was produced so it can compare that against revocation and expiration dates. Note: technically cryptographic timestamping allows a client to verify that something was produced on or before a given date, not the date that the data was necessarily produced, but that distinction is beyond the scope of this post.
Best Practices
Given the complexities of revocation, the mixed support for it by common clients, and the ramifications of improper usage, what should an enterprise do? Two best practices to follow are:
1. Use cryptographic timestamping
2. Use short-lived certificates
Number 1 is pretty simple to use – just specify a publicly trusted timestamping service when signing data. Some tools automatically do this for you and others require you to do it yourself. Number 2 requires automated certificate lifecycle management (CLM) because without it certificates may expire resulting in costly outages. CLM has traditionally been very expensive but that is no longer the case. GaraSign provides unlimited certificate lifecycle management that will not break the bank. Get in contact with us today to learn more.
