Certificate Revocation List

Certificate Revocation List (CRL) is a signed list published by a Certificate Authority that identifies X.509 certificates revoked before their stated expiration, allowing relying parties (browsers, operating systems, and enterprise clients) to reject certificates that should no longer be trusted. In the Web PKI, CRLs are one of the primary mechanisms for certificate revocation and a practical control point that can affect site availability and incident response at Internet scale.

How CRLs work

A CA issues a CRL periodically and signs it so clients can validate authenticity via the CA’s chain. Certificates commonly include pointers to where a client can retrieve the relevant CRL (CRL Distribution Points). Revocation checking therefore depends not only on the CA’s decision to revoke, but also on timely publication and on clients actually using the information.

CRLs and OCSP

CRLs coexist with the Online Certificate Status Protocol (OCSP), which provides per-certificate status queries instead of downloading a list. At Internet scale, OCSP has been criticized for privacy and availability trade-offs (status queries can reveal browsing targets; responder failures create operational risk), contributing to renewed emphasis on CRL-based approaches and CRL-derived distribution models.

Internet governance implications

CRLs matter for Internet governance because revocation is an enforcement mechanism in the Web PKI that operates alongside DNS and hosting controls, often with different decision-makers and escalation paths. A CA’s revocation decision can invalidate a certificate before its scheduled expiry, which can effectively break HTTPS service for a domain without any change to DNS delegation or content hosting. This makes revocation a rapid-response tool for compromise or mis-issuance, but it also creates the possibility of “takedown-by-revocation” dynamics where availability is impacted through trust infrastructure rather than naming infrastructure.

The practical impact of a CRL is mediated by relying-party software. Browsers and operating systems determine whether revocation is checked by default, how failures are handled (e.g., whether missing revocation data blocks a connection or is ignored), and whether alternative distribution approaches are used. As a result, a relatively small number of trust programs, client vendors, and CA ecosystems can exert outsized influence over which revocations produce real-world effects, and on what timelines, even when the underlying certificate and revocation data are standardized.

CRLs also introduce cross-border operational dependencies. Because CRL Distribution Points typically reference CA-controlled network endpoints, the ability of clients to retrieve revocation information can be affected by outages, routing incidents, blocking, or jurisdictional constraints that impact access to CA infrastructure. This can produce uneven revocation enforcement across regions and networks, with security and availability consequences that are not evenly distributed.

Finally, revocation mechanisms create governance-relevant privacy trade-offs. Per-certificate querying models like OCSP can expose user browsing targets to third parties, while CRL-based or CRL-derived approaches are often framed as ways to reduce per-visit disclosure and improve scalability. Shifts in ecosystem practice therefore reflect broader choices about privacy-by-design, centralization, and the extent to which security enforcement should rely on centralized distribution and client-side telemetry to achieve coverage.

X.509 Public Key Infrastructure for the Internet (RFC 5280).

HTTP over Transport Layer Security (TLS), distinguishing secured traffic from insecure traffic by the use of a different server port (RFC 2818).