Skip to content

CONCEPT Cited by 2 sources

Certificate revocation

Definition

Certificate revocation is the mechanism that makes a certificate untrusted before it expires — for example, because its private key is compromised or it was mis-issued. In the Web PKI the classic mechanisms are CRLs (signed lists of revoked serial numbers, published by the CA) and OCSP (an online per-certificate status query). Both have known weak points: CRLs are large and slow to fetch, and OCSP adds latency and a privacy leak, and clients often soft-fail (accept the certificate) when the check cannot complete. Because of this, the industry has moved toward browser-pushed aggregate lists (Chrome CRLSets, Firefox CRLite), short-lived certificates that make revocation less necessary, and — as the terminal action — distrust: the root store removes or blocks a CA or intermediate.

Revocation is the "undo" for the chain of trust. When a key high in the chain is compromised, everything below it is forgeable until every verifier learns to reject that key.

Revocation reach is the bottleneck

The eMudhra incident (2026-10) shows that the hard part is not deciding to revoke but reaching every verifier:

  • Browsers remediate "with a flip of a switch". They are one application with a quick-revocation channel (for example Chrome CRLSets), so distrust of the eight weak intermediates reached them fast. (Source: sources/2026-10-20-cloudflare-emudhra-certificates-compromised)
  • The long tail does not. OS trust stores, language runtimes, HTTP libraries, SDKs, and container images each carry their own trust store and update on their own schedule. Ten days after the incident, Cloudflare's challenge-page probes found that Android WebView still accepted the weak chain at 30–40%, and across large networks more than half of probes accepted it, with a flat trend after the first weekend. (Source: sources/2026-10-30-cloudflare-emudhra-patching)
  • The CA's own revocation artefacts can be suspect. eMudhra first signed a CRL with what may have been a correctly generated key, then re-signed it with the weak key. (Source: sources/2026-10-30-cloudflare-emudhra-patching)

The design response: trust stores as a fast-update channel

Both Cloudflare posts argue that "a trust store can't be a static list of root certificate authorities": it must be quickly updatable with revocation data and CT log keys. This generalizes the CRLSet/CRLite idea from browsers to every TLS client. Projects like upki (under the rustls organization) aim at this. Cloudflare already runs a quick-revocation mechanism in some products and plans to extend it. (Sources: sources/2026-10-20-cloudflare-emudhra-certificates-compromised, sources/2026-10-30-cloudflare-emudhra-patching)

A related defense is CT enforcement: a client that requires SCTs rejects a forged certificate that was never logged, even if the issuing key is not yet revoked on that client. (Source: sources/2026-10-30-cloudflare-emudhra-patching)

Measuring revocation reach

You cannot ask a client which keys it trusts. Cloudflare measured it indirectly: background probes from Challenge Pages to a weak-chain endpoint and a control endpoint, recording which succeed. This is a RUM-style population signal with strong selection bias (bots, JavaScript-only clients). (Source: sources/2026-10-30-cloudflare-emudhra-patching)

Seen in

  • sources/2026-10-20-cloudflare-emudhra-certificates-compromised — eight eMudhra intermediates with weak keys; browsers distrust quickly via CRLSets; the long tail needs updates to shared trust stores, base images, and SDK dependency trees; argument for updatable trust stores (upki).
  • sources/2026-10-30-cloudflare-emudhra-patching — the measurement follow-up: revocation reach, quantified. Android WebView 30–40% still accept;

    50% of probes in large ASNs accept; the CRL re-signed with the weak key; quick revocation in more systems as the goal.

Last updated · 854 distilled / 2,448 read