A CRL is a signed list of certificates that a CA has revoked before their expiration date. Think of it as a cancelled passport list: authorities publish it so that anyone checking a passport can verify it hasn't been invalidated. This guide explains how CRLs work, how they compare to OCSP, and best practices for managing them.
A Certificate Revocation List (CRL) is a digitally signed data structure published by a certificate authority (CA) that lists the serial numbers of certificates that have been revoked before their natural expiration date.
The CRL format is defined in RFC 5280 as part of the X.509 standard. Each CRL entry contains the certificate's serial number, the revocation date, and optionally a reason code. The entire list is signed by the CA's private key, so clients can verify its authenticity.
Think of a CRL like the list of cancelled credit cards that merchants used to receive: a periodically updated document that says "these credentials are no longer valid, even though they haven't expired yet." Clients download the CRL and check incoming certificates against it.
RFC 5280 defines specific reason codes for certificate revocation. Understanding these helps explain why CRLs exist and why revocation checking matters.
The certificate's private key has been exposed, stolen, or is suspected of being compromised. This is the most urgent reason for revocation, as the key could be used to impersonate the certificate holder.
The CA's own private key has been compromised. All certificates issued by that CA must be revoked. This is catastrophic and has happened in real incidents like the DigiNotar breach in 2011.
The certificate holder's relationship with the organization named in the certificate has changed. For example, an employee leaves the company and their client authentication certificate should be revoked.
A new certificate has been issued to replace this one. The old certificate is revoked to prevent two valid certificates from coexisting for the same identity.
The CA periodically generates a new CRL containing all currently revoked certificates. The CRL is signed with the CA's private key and published at a URL called the CRL Distribution Point (CDP). The CDP URL is embedded in every certificate the CA issues.
When a client (browser, application, or server) needs to verify a certificate, it reads the CDP from the certificate and downloads the CRL. The client then verifies the CA's signature on the CRL to ensure it hasn't been tampered with.
The client searches the CRL for the certificate's serial number. If found, the certificate is revoked and the connection is rejected. If not found, the certificate passes the revocation check.
Each CRL has a nextUpdate field indicating when a new CRL will be published. Clients cache the CRL until this time, avoiding repeated downloads. The trade-off: during the cache period, newly revoked certificates won't be detected.
CRL and OCSP are both mechanisms for certificate revocation checking, but they work very differently.
| CRL | OCSP | |
|---|---|---|
| Mechanism | Download full list | Real-time query per certificate |
| Freshness | Periodic (hours to days) | Near real-time |
| Bandwidth | Full list each time (can be large) | Small per-certificate response |
| Privacy | No per-request tracking | CA sees which certs are checked |
| Offline support | Works with cached CRL | Requires network access |
| Standard | RFC 5280 | RFC 6960 |
In practice: Most modern deployments use both. OCSP provides fast, real-time checks for TLS connections, while CRLs serve as a fallback and are used by systems that need offline revocation checking. OCSP Stapling (where the server includes the OCSP response in the TLS handshake) eliminates the privacy and latency concerns of direct OCSP.
You can download and inspect CRLs using OpenSSL. Here's how to examine a CRL from any CA.
# Download a CRL from its distribution point
curl -o ca.crl http://crl.example.com/ca.crl
# Parse and display the CRL contents (DER format)
openssl crl -in ca.crl -inform DER -noout -text
# Key fields to check:
# Issuer: the CA that published this CRL
# Last Update: when this CRL was generated
# Next Update: when the next CRL will be published
# Revoked Certificates: list of serial numbers + dates# Check if a specific certificate is on the CRL
openssl crl -in ca.crl -inform DER -noout -text | \
grep "Serial Number: 0A1B2C3D"
# Verify the CRL signature against the CA certificate
openssl crl -in ca.crl -inform DER -CAfile ca-cert.pem -nooutYou can also use the Evertrust Crypto Decoder to paste and parse CRLs visually, without needing command-line tools.
CRLs only grow: every revoked certificate adds an entry until the certificate's original expiration date passes. A busy CA can produce CRLs that are megabytes in size. Clients must download the entire list even if only one entry changed.
Large CRLs consume significant bandwidth, especially when many clients download them simultaneously after a nextUpdate window expires. This creates traffic spikes on the CDP infrastructure and adds latency to certificate validation.
Between CRL publications, newly revoked certificates are invisible to clients using cached CRLs. If the CRL is published every 24 hours, a compromised certificate could remain trusted for up to 24 hours after revocation. This is the fundamental trade-off of CRL's batch model.
Delta CRLs (RFC 5280) address the size problem by publishing only changes since the last full CRL. However, they add significant complexity: clients must track base CRL numbers, handle delta references, and manage cache coherency. Many implementations don't support them.
Reduce the window of vulnerability by publishing CRLs frequently. For issuing CAs handling TLS certificates, publish at least every 4 to 6 hours. For high-security environments, consider hourly publication.
Configure multiple CRL Distribution Points in your certificates for redundancy. If one CDP is unavailable, clients can fall back to another. Use CDN hosting for public CRLs to handle traffic spikes.
Deploy OCSP alongside CRL for defense in depth. OCSP provides real-time revocation status with lower bandwidth, while CRLs serve as the authoritative fallback. Enable OCSP Stapling on your web servers.
Set up monitoring for CRL freshness (is the CRL being published on schedule?), size (is it growing unexpectedly?), availability (are CDPs responding?), and validity (is the signature correct?). A stale CRL can cause widespread certificate validation failures.
Automated CRL and OCSP: Evertrust PKI automatically publishes CRLs on configurable schedules and provides a built-in OCSP responder. Both are managed without manual intervention, ensuring revocation information is always fresh and available.
Revocation visibility: Evertrust CLM tracks the revocation status of every discovered certificate across all your CAs. See which certificates have been revoked, when, and why, from a single dashboard.
Revocation + replacement workflow: When you revoke a certificate in Evertrust, you can automatically trigger the issuance and deployment of a replacement certificate, minimizing the time your service runs without a valid certificate.