What a CRL is

A CRL is exactly what its name says: a list of revoked certificates. The CA generates it, signs it, and publishes it to a known URL. Every X.509 certificate issued by that CA carries a CRLDistributionPoints extension pointing at the URL. Relying parties fetch the CRL, check whether the certificate's serial number is on it, and decide to trust or reject accordingly.

The format is specified in RFC 5280 §5. The structure is ASN.1 DER-encoded and signed by the CA (or a dedicated CRL signer). Key fields:

thisUpdate — when this CRL version was generated
nextUpdate — when the next version is expected (also how long to cache)
revokedCertificates — the list, each entry carrying a serial number, revocation date, and optional reason code
Signature — covers the entire structure

What CRL does well

Universal client support. Every TLS implementation since the mid-1990s understands CRLs. OpenSSL, Java's JSSE, Microsoft SChannel, Go's crypto/x509 — all speak CRL.
Cacheable. A single CRL fetch serves millions of relying parties through CDN edge caches. The CA pays one bulk publishing cost; relying parties get fast cached reads.
Offline-friendly. A client with a recent CRL can validate certificates without any live network round-trip to the CA.
Resilient to CA outages. If the CA's CRL publishing infrastructure goes down for an hour, cached CRLs still work.

Where CRL breaks

File size

Every revoked certificate stays in the CRL until it would have expired naturally. A busy CA accumulates. Public CAs with millions of issued certificates and even modest revocation rates generate CRLs in the tens of megabytes. Every TLS handshake that validates against the CRL has to download and parse that file (or rely on CDN caching).

Freshness lag

The default ADCS CRL publication cadence is daily. Even with delta CRLs enabled at 5-minute intervals, a certificate revoked at 00:00:30 isn't visible to relying parties until the next delta publication. In a 47-day certificate world this gap matters a lot.

Cache invalidation trade-off

Short nextUpdate: relying parties refetch often, bandwidth costs go up.
Long nextUpdate: revocation propagation window gets longer.

There's no "cheap and fresh" option.

Soft-fail by default

Most non-browser TLS clients soft-fail on CRL fetch errors — if the distribution point is unreachable, the cert is considered valid. A reachable DNS + a firewalled CRL URL = successful revocation bypass.

Delta CRL

A delta CRL is a smaller companion CRL that lists only the certificates revoked since the last full CRL. Delta CRLs can be published more frequently (every 5 minutes is common) without the bandwidth cost of a full CRL.

Clients combine the last full CRL with the latest delta to reconstruct the current revocation list. Most modern TLS stacks support delta CRLs, though support in older or embedded clients is uneven.

When CRL is still the right answer

Air-gapped or constrained-connectivity environments. OCSP requires live round-trips; CRL works from a cache.
High-volume validation where OCSP responder load would be prohibitive. A single CRL serves millions; OCSP requires per-cert queries.
Validation inside an environment with its own CRL mirror. Internal PKI can push CRLs to an internal mirror and configure clients to fetch from there.
As a backup to OCSP. OCSP responders fail. CRL cached on the client is a safety net for the duration of the outage.

CRLSet (Chrome) and OneCRL (Firefox)

Browser vendors supplement CRL with their own curated revocation lists for high-impact events:

Chrome's CRLSet — a signed list of known-bad intermediates pushed to every Chrome instance out-of-band via the browser update channel. Updated when a CA incident lands (eMudhra, DigiNotar, Symantec).
Mozilla's OneCRL — Firefox's equivalent, updated through Remote Settings every 24 hours.
Apple's blocklist — same idea for Safari.

These are not replacements for CRL — they're supplements for cases where the CA machinery is too slow.

CRLite (Mozilla)

An ambitious attempt to push all revocations to every browser in a compressed Bloom filter. Each update is still small enough to ship with normal browser updates but covers every known revocation. CRLite is shipping in Firefox; it does not help non-browser clients.

Operational recommendations (2026+)

For internal CAs:

Enable delta CRLs on a 5-minute cadence.
Keep the full CRL on a weekly cadence as a backup.
Serve CRLs over HTTP (not HTTPS) — the CRL itself is signed, HTTPS adds no security and complicates chain validation.
Cache-control headers matched to nextUpdate.
Monitor CRL nextUpdate. If you're about to miss it, the CA is about to fail validation at every relying party.

For non-browser client configuration:

Hard-fail revocation where possible. Soft-fail is the default; it's also the problem.
Local CRL mirror for air-gapped segments.
Alert on CRL fetch failures. A reachable DNS + a timeout = silent revocation bypass.

CRL