Revocation of X.509 certificates | APNIC Blog

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.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 of all unexpired revoked certificates it has issued, and the time of revocation. A CRL also contains the date of its own issuance and the anticipated date when the next CRL will be published. CRLs are signed with the private key of the CA. A standard profile for CRLs for use on the Internet is published in RFC 5280. An example CRL is shown below.$ wget http://e8.c.lencr.org/111.crl $ openssl crl -inform DER -text -noout -in 111.crl Certificate Revocation List (CRL): Version 2 (0x1) Signature Algorithm: ecdsa-with-SHA384 Issuer: C=US, O=Let's Encrypt, CN=E8 Last Update: Apr 22 01:42:43 2026 GMT Next Update: May 1 01:42:42 2026 GMT CRL extensions: X509v3 Authority Key Identifier: 8F:0D:13:A2:F6:2E:7E:D1:50:6C:33:18:38:5D:59:8E:23:72:91:CA X509v3 CRL Number: 1776822163859760709 X509v3 Issuing Distribution Point:

critical Full Name: URI:http://e8.c.lencr.org/111.crl Only User Certificates Revoked Certificates: Serial Number: 05F5F9651D5AA120AFFB590755A2C51979EE Revocation Date: Jan 21 01:06:17 2026 GMT Serial Number: 063914206A1E038705B852D44A5051E3396E Revocation Date: Jan 21 04:33:49 2026 GMT [repeated 1,560 times] Signature Algorithm: ecdsa-with-SHA384 Signature Value: 30:66:02:31:00:b7:59:6a:b2:61:fc:d5:57:92:1e:5c:08:86: 11:77:7a:c0:91:07:3c:b3:32:62:6b:d4:d8:6b:7a:d9:33:9c: ea:a1:e9:5d:a5:75:e7:d0:cb:f4:a1:65:d5:47:94:21:0c:02: 31:00:86:7b:d7:6b:14:19:7a:8d:ad:2e:ec:d8:e5:ce:83:ad: 3e:7d:57:84:21:09:38:af:31:90:97:32:74:61:f5:b8:59:1a: 89:68:ef:66:03:43:fd:12:71:b6:8d:e1:b8:14

The CRL is intended to list all unexpired revoked certificates issued by this CA in a given scope at the date specified by the Last Update field of the CRL. If the scope of the CRL is the entire set of certificates issued by this CA, then any unexpired certificate that is not listed in the CRL can be trusted (used as a valid certificate) until the next CRL issuance time.End users (‘relying parties’) can consider a CRL itself to be valid if the current time is between the CRL time and the CRL’s nextUpdate time, and the CRL’s signature can be validated.Having a certificate listed in a CRL effectively curtails a certificate’s validity, but the effect is not necessarily immediate across the broader domain of use. A relying party may hold a local copy of an issuer’s CRL until the CRL’s nextUpdate time, and therefore revocation may not be visible to relying parties until the next CRL is published. While a CRL can curtail a certificate’s lifetime before its scheduled expiration date, the CRL may not necessarily be up to date, and may lag by as much as the CRL’s publication interval. In the case of the CRL above, there is a nine-day window where a relying party may be unaware that an issued certificate may have been revoked. In practice, a CRL improves the timeliness of certificate currency from years to a week or so. It’s still not immediate, but it’s an improvement.How can a client check the revocation status of a certificate that is presented to it when starting a TLS session? The CRL procedure entails: Find the CRL publication URL in the certificate provided as part of the TLS handshake Retrieve the CRL Validate that the digital signature was generated by the CA’s private key, and create a validation chain to a TA Validate the currency of the CRL with the update date of the CRL Look for the certificate’s serial number in the CRL If the certificate was revoked prior to the CRL issue date, then its serial number will be listed in this CRL. If it cannot be found in the CRL, then either the certificate has not been revoked, or, more accurately, it had not been revoked at the time of the CRL creation date.More unexpired revoked certificates mean larger CRLs.