Revocation of X.509 Certificates

This is not the first time I’ve looked at Domain Name Certificate revocation in these blog articles, first in 2020 and again in 2022 — it’s an evolving story. There have been several recent changes by the Certificate Authority and Browser Forum (CAB Forum) and the largest Certification Authority, Let’s Encrypt, which have a fundamental impact on the way in which we use (and trust) these certificates. I thought it would be useful to look at the topic of certificate revocation once more in the light of these changes.

Public Key Infrastructure (PKI) is a system designed to support the use of public/private keyed digital signatures through a system of structured transitive trust. The objective of a PKI is to enable trusted communications between parties who may have never directly met and may not necessarily even know each other at all.

A PKI normally uses X.509 public key certificates, which are digital objects that contain:

• A verifiable attestation that the certificate issuer has satisfied itself using application procedures documented in its Certificate Practice Statement
• An assertion that the holder of a given public/private key pair has met certain criteria as specified by the certificate issuer

The certificate issuer then publishes a certificate that associates a subject name (such as an individual’s details for identity certificates or a DNS name for a domain name certificate) with the holder’s public key. It then attaches a digital signature to this object, generated using the certificate issuer’s private key. This act is both verifiable by any party that has knowledge of the issuer’s public key and cannot be subsequently repudiated by the issuer.

X.509 public key certificates support several purposes, including authenticity, verifiability, and attribution. They can also help establish an encrypted session. For example, if an individual signs a digital document with their certified private key, anyone who refers to the associated public key identity certificate can validate (verifiability) that it was this particular individual who signed the document (attribution), and the document is unaltered (authenticity), as long as they are prepared to trust the integrity of the certificate issuance practices of the certificate issuer. If a client uses a server’s public key as part of the process of setting up a session key, the client and server can exchange encrypted messages that can only be deciphered by each other (encryption), such as in the use of keys by Transport Layer Security (TLS).

We see widespread use of domain name public key certificates in the web, where clients can access servers’ published content and online services using Transport Layer Security (TLS), as seen in the use of HTTPS URLs. The use of the web PKI allows a client to validate the authenticity of the remote server’s identity and encrypt the ensuing access session, ensuring that:

• The transaction cannot be eavesdropped on by third parties
• The contents of the transaction are not altered in any way
• The server cannot repudiate the transaction

Obviously, this level of trust is vital for the Internet, making TLS one of the foundational protocols for the Internet. If I had to nominate just a handful of critical, common Internet protocols, I’d say that TLS ranks alongside DNS and HTTP. This means that the web PKI system of domain name certification is also critically important to the Internet. I’d go further and argue that, across a range of Internet security mechanisms, including DNSSEC and RPKI, we rely heavily on these domain name certificates to provide the assurance that we are not being misled.

X.509 Public Key Certificates enable transitive trust (on the basis that if Alice trusts every action of Bob’s and Bob trusts Carol, then Alice can trust Carol). However, trust is never eternal, including the implicit trust described in a certificate.

An X.509 Public Key Certificate has two date fields, notBefore and notAfter, specifying the timespan during which the certificate can be used. It must be noted that RFC 5280 does include the specification of a ‘forever’ notAfter date value if eternal trust really is the intended outcome! But using this value would be an incredibly foolhardy action! The usual practice of certification management is to set the notBefore field to the date of certificate issuance, and the notAfter field to some period specified by a contract or agreement between the certificate issuer and the subject.

The subject is expected to apply for a new certificate before the expiration of the current certificate if they wish to continue to be certified beyond the notAfter date. Before Let’s Encrypt’s entry into the Secure Socket Layer (SSL) certification market, typical certification periods were one or two years. Let’s Encrypt is now a major player, and its certificates have a 90-day validity period, so the average validity period for these certificates has come down. There is a change coming in these Let’s Encrypt certificates next month, in May 2026, but we’ll discuss this further on in this article.

There are circumstances where the certificate should be marked as unusable immediately, which is before the notAfter expiration time. The private key may have been compromised, or the certificate was issued in error, or the subject is no longer undertaking the activity or service for which it was certified, and so on. The subject may want a new certificate issued before its current certificate expires, and retire the old certificate as soon as its replacement is brought into service. Or the certificate issuer may have been compromised. These things happen.

Revocation

How can a certificate be marked as unusable (or be revoked) before its scheduled expiration time?

The certificate issuer should remove the revoked certificate from its online publication point, so that the revoked certificate is no longer available for upload and use by relying parties.

But that’s not good enough. There are many reasons for certificate users to gather and locally store copies of such certificates. My web server, for example, uses a local copy of the server name’s certificate to support secure sessions. When a client starts a TLS session with this server, how is the client meant to know that the certificate being used to set up this secure session has been revoked? The client needs a way to check whether the certificate is still trustworthy.

Before looking at revocation mechanisms, I should note one rather esoteric point about revocation, namely its irrevocability.

Revoking a certificate causes the Certification Authority (CA) to create a metadata record about the unusable status of the certificate in a special list of revoked certificates. The list is called — imaginatively — a Certificate Revocation List (CRL), digitally signed by the CA to attest to its authenticity.

The CA does not issue an altered replacement certificate that records its revoked status within the certificate itself. The entry in the CRL is the only record that the certificate must not be used. A CA could, in theory, subsequently remove the listing of the revoked status of the certificate in the CRL. Because the certificate itself has not been altered in any way, it could restore the certificate to its publication point. In effect, the published certificate state after this removal of the revocation metadata would be the same as it was before the revocation action. The certificate has been unrevoked.

In practice, this would be a truly terrible idea, and CAs must never attempt this! The only permitted way to signal the reinstatement of trust is by issuing a new certificate for the same subject with a new serial number. It would be prudent for the subject to use a new public/private key pair in this case.

A conventional PKI response to manage revocation is for the CA to regularly publish a signed CRL. The list contains all of the certificate serial numbers.