What is CRL (Certificate Revocation List)

A Certificate Revocation List (CRL) is a signed document published by a Certificate Authority containing the serial numbers of all certificates it has revoked before their natural expiry. When a client needs to verify whether a certificate is still trusted, it downloads the CRL from the URL specified in the certificate’s CRL Distribution Points extension, checks if the certificate’s serial number appears in the list, and rejects the connection if it does. CRLs are the original revocation mechanism in X.509 PKI — simple in concept, problematic at scale.

Why it matters

• Revocation is the only way to kill a certificate early — if a private key is compromised, the certificate remains valid until expiry unless explicitly revoked. CRLs are the broadcast mechanism that tells clients “don’t trust this anymore.”
• Offline verification — unlike OCSP (which requires a network query per certificate), a downloaded CRL can be cached and checked locally. Useful for air-gapped systems and environments with intermittent connectivity.
• Enterprise PKI requirement — Microsoft AD CS, EJBCA, and most enterprise CAs publish CRLs. Windows domain-joined machines check CRLs for certificate validation. If the CRL is unreachable, certificate validation may fail (depending on configuration).
• Compliance mandate — standards like Common Criteria, FIPS, and many government PKI policies require CRL publication as a revocation mechanism, even when OCSP is also available.
• Scalability problem — a CA that has revoked 100,000 certificates has a CRL with 100,000 entries. Every client must download this entire list to check one certificate. This is why OCSP and CRLite were invented.

How it works

1. CA revokes a certificate — operator (or automated system) marks a certificate as revoked in the CA database, with a reason code (keyCompromise, cessationOfOperation, superseded, etc.).
2. CRL generation — CA generates a new CRL containing all currently-revoked serial numbers, signs it with the CA’s private key, and sets thisUpdate (generation time) and nextUpdate (when the next CRL will be published).
3. CRL publication — the signed CRL is published to the URL(s) specified in issued certificates’ CRL Distribution Points (CDP) extension. Typically an HTTP URL or LDAP directory.
4. Client obtains CRL — during certificate validation, the client fetches the CRL from the CDP URL. The CRL is cached until nextUpdate.
5. Client checks serial number — searches the CRL for the certificate’s serial number. If found: certificate is revoked, reject the connection. If not found: certificate is not revoked (as of this CRL’s publication time).
6. CRL refresh — when nextUpdate passes, the client fetches a fresh CRL. Between publications, newly-revoked certificates are invisible to clients.

In real systems

Microsoft AD CS CRL configuration:

# CRL publication settings (typical enterprise):
# - Base CRL: published every 1 week
# - Delta CRL: published every 1 day
# - CDP: http://pki.example.com/crl/IssuingCA.crl
# - CDP: ldap:///CN=IssuingCA,CN=server,CN=CDP,CN=Public Key Services,...

# Check CRL publication status:
certutil -crl
# Verify a certificate's revocation status:
certutil -verify -urlfetch cert.pem

Nginx CRL checking (client certificate validation):

server {
    ssl_client_certificate /etc/ssl/client-ca.pem;
    ssl_verify_client required;
    ssl_crl /etc/ssl/crl/client-ca.crl;  # Must be refreshed periodically!
}
# WARNING: Nginx loads the CRL at startup. If the CRL file isn't updated,
# revoked client certificates will still be accepted.

OpenSSL CRL verification:

# Download CRL
curl -o issuer.crl http://pki.example.com/crl/IssuingCA.crl

# Verify certificate against CRL
openssl verify -crl_check -CRLfile issuer.crl -CAfile ca-chain.pem cert.pem

# Inspect CRL contents
openssl crl -in issuer.crl -noout -text
# Shows: Issuer, Last Update, Next Update, Revoked Certificates (serial + date + reason)

Java application CRL checking:

// Enable CRL checking in Java TLS
System.setProperty("com.sun.security.enableCRLDP", "true");
// Java will automatically fetch CRLs from CDP URLs in certificates
// WARNING: If CDP is unreachable, validation fails (hard-fail by default in Java)

Where it breaks

CRL not published on time — the CA is configured to publish a new CRL every 7 days. The CA server goes down on day 5. On day 7, the old CRL’s nextUpdate passes. Clients that enforce CRL freshness now reject ALL certificates from this CA — not just revoked ones — because they can’t get a valid CRL. The CA’s availability directly affects every certificate it has issued. This is why CRL publication must be monitored and the CA must have high availability for CRL generation.

CRL too large for constrained clients — a CA has revoked 50,000 certificates over its lifetime. The CRL is 2MB. IoT devices on cellular connections (paying per KB) must download this entire list to validate one certificate. Delta CRLs help (only new revocations since last base CRL), but many clients don’t support them. At scale, CRLs become a bandwidth and latency problem that OCSP was designed to solve.

Nginx CRL not refreshed — Nginx loads the CRL file at startup (or reload). If the CRL file on disk isn’t updated before nextUpdate, Nginx continues using the stale CRL. Certificates revoked after the last CRL update are still accepted. A cron job must periodically download the fresh CRL and reload Nginx. If this automation breaks, revocation checking silently stops working.

Operational insight

The fundamental weakness of CRLs is the publication delay. Between CRL publications (typically 1-24 hours for enterprise CAs, up to 7 days for some), a revoked certificate is still trusted by every client using the cached CRL. If a private key is compromised and the certificate is revoked immediately, attackers have a window (until the next CRL publication) where the revoked certificate still works. For high-security environments, this means CRL publication intervals must be short (1-4 hours), which increases CA load and client bandwidth. The trade-off between publication frequency and resource consumption is the core operational tension of CRL-based revocation.

Related topics

• What is OCSP
• Certificate Renewal and Revocation
• What is a Certificate Authority
• Certificate Monitoring and Alerting
• Root CA vs Intermediate CA