↓ Skip to main content
Le Site de François
  1. Index/

CRL (Certificate Revocation List)

Security Pki X509 Certificates Revocation Tls

A Certificate Revocation List (CRL) is a signed data structure, published by a Certificate Authority as part of its PKI operations, that lists the serial numbers of X.509 certificates the CA has revoked before their scheduled expiry date. A CA revokes a certificate when its private key is compromised, the subject’s identity information changes, the certificate was mis-issued, or the subject is no longer authorised. Without revocation, a compromised certificate remains trusted by all verifiers until it expires — which for long-lived CA and infrastructure certificates can be years. The CRL is the oldest revocation mechanism, defined in RFC 5280 alongside the X.509 v3 certificate format, and remains widely deployed for CA certificates, code signing certificates, and client certificates in contexts where OCSP is impractical.

A CRL is itself a signed JWT-like structure in ASN.1/DER format: a tbsCertList (the list body containing the issuer DN, the signature algorithm, the thisUpdate timestamp, the optional nextUpdate timestamp, and the list of revoked certificate entries — each entry carrying the serial number, the revocation date, and optional reason code) plus the CA’s signature over that body. Verifiers download the CRL from the URL specified in the certificate’s CRL Distribution Point (CDP) extension, verify the CA’s signature, check that thisUpdate is not in the future and nextUpdate is not in the past (ensuring freshness), and search for the certificate’s serial number. If found, the certificate is revoked; if absent, it is currently valid. CRL reason codes (RFC 5280 §5.3.1) include keyCompromise, cACompromise, affiliationChanged, superseded, cessationOfOperation, certificateHold, removeFromCRL, and privilegeWithdrawn — the reason is informational for the verifier, but keyCompromise and cACompromise carry a revocationDate that may be set earlier than the actual compromise discovery, affecting retroactive validation. Delta CRLs (RFC 5280 §5.2.4) are incremental updates listing only changes since the last full CRL, reducing download size for large CRLs by allowing verifiers to apply deltas on top of a cached base CRL.

CRLs have three well-known operational problems that drove the development of OCSP. Staleness: a CRL is only as current as its last publication; if a CA publishes CRLs every 24 hours and a certificate is compromised at 00:01, it will not appear in a CRL until at most 23:59 later — during which time the certificate appears valid to all verifiers. Size: a CA that has issued millions of certificates and revoked hundreds of thousands of them produces a CRL that may be tens or hundreds of megabytes, impractical to download per connection. Privacy: every verifier that downloads a CRL reveals to the CRL distribution point server which CA’s certificates it is checking, though not which specific certificate. These limitations make CRLs unsuitable as the primary revocation mechanism for web PKI leaf certificates — browsers have largely abandoned per-connection CRL fetching, relying instead on OCSP stapling or browser-vendor aggregated revocation lists (Chrome’s CRLSets, Firefox’s OneCRL). CRLs remain the correct mechanism for CA certificate revocation (where size is small and staleness is acceptable since CA certificates have long validity), for code signing certificates in offline verification scenarios (air-gapped environments can cache a CRL and verify signatures without network access), and for client certificate revocation in mTLS environments where the server controls the verification policy and can configure a tolerable maximum CRL age. In the PQC transition, CRL signatures must migrate from ECDSA/RSA to ML-DSA alongside the certificates they cover — a CA that migrates to an ML-DSA signing key must also re-sign its CRLs under the new key, and verifiers must be updated to accept ML-DSA CRL signatures.

Related

OCSP (Online Certificate Status Protocol)

Security Pki X509 Certificates Revocation Tls
OCSP (Online Certificate Status Protocol), standardised in RFC 6960, is a request-response protocol that allows a verifier to query an OCSP responder — a service operated by the CA or a delegated party — for the current revocation status of a specific X.509 certificate. Where a CRL requires downloading an entire list and searching it locally, an OCSP query asks about exactly one certificate and receives a signed response: good (the certificate is currently valid and not revoked), revoked (revoked, with the revocation time and reason), or unknown (the responder does not know this certificate). The OCSP response is signed by the CA’s OCSP signing key (or a dedicated OCSP responder key with the id-pkix-ocsp-nocheck extension, exempt from its own revocation checking to prevent circularity) and carries a thisUpdate and nextUpdate timestamp defining its freshness window. Verifiers in strict mode reject responses outside the freshness window; in practice, OCSP responses are valid for 24 hours to 7 days depending on the CA’s policy, meaning OCSP shares CRL’s staleness problem, albeit with a smaller window.

PKI (Public Key Infrastructure)

Security Cryptography Certificates Identity Tls Pki
Public Key Infrastructure (PKI) is the framework that makes asymmetric cryptography operationally useful at scale. Asymmetric cryptography provides a mathematical relationship between a public key and a private key, but by itself it cannot answer the question a relying party cares about: whose public key is this? PKI answers that question by introducing a trusted third party — the Certificate Authority (CA) — that cryptographically binds a public key to an identity (a hostname, an organisation name, an email address, a SPIFFE ID) by signing a certificate. A relying party that trusts the CA can therefore trust any certificate the CA signs, without needing to know the subject directly. The chain of trust extends recursively: a Root CA signs Intermediate CA certificates, which sign end-entity certificates (also called leaf certificates). Root CA private keys are kept offline in HSMs and used rarely; intermediate CAs handle day-to-day issuance and can be revoked without rotating the root. The set of root CA certificates a system trusts is its trust store — browsers and operating systems ship with a pre-populated trust store of publicly-trusted roots, while private PKIs use custom roots distributed by administrators.

X.509

Security Cryptography Certificates Pki Tls Standards
X.509 is the ITU-T standard (first published in 1988, currently at version 3) that defines the structure of a digital certificate: a signed data structure that binds a public key to an identity and a set of constraints, issued by a Certificate Authority whose signature vouches for the binding. It is the near-universal format for certificates in PKI, TLS, code signing, S/MIME encrypted email, SPIFFE X.509-SVIDs, and SSH host certificates. When someone refers to a TLS certificate, a CA certificate, or a code-signing certificate, they are referring to an X.509 certificate. The format is defined using ASN.1 (Abstract Syntax Notation One) and most commonly serialised as DER (Distinguished Encoding Rules, binary) or PEM (base64-wrapped DER with -----BEGIN CERTIFICATE----- headers, the format seen in most configuration files).