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.
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.
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.
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.
| 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 |
# 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 -nooutAutomated 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.