When a certificate authority is distrusted: trust-store response runbook
What to do when a certificate authority's keys are compromised or a root program stops trusting it. Browsers fix themselves within hours; the long tail is everything else that carries its own copy of the trust store, plus any of your own certificates that chain to the distrusted CA.
Why this needs a runbook. Every TLS client decides which certificate authorities (CAs) to trust from a trust store: a list of root certificates. There is not one list but many. Browsers and operating systems run root programs (Mozilla, Chrome, Apple, Microsoft), and a long tail of software ships its own copy, usually derived from Mozilla's: Linux ca-certificates packages, the curl CA bundle, Python certifi, Go, Java cacerts, Node.js, Electron apps, container base images and appliances. When a CA is distrusted, each of those copies has to be updated separately, and some never will be.
How trust is withdrawn
Revocation by the CA. The CA marks the certificate revoked on its CRL (and OCSP, where it still runs one). This only protects clients that actually check, and many non-browser clients do not check revocation at all or fail open when the check cannot complete.
Browser push lists. Browsers do not wait for CRLs. Chrome uses CRLSets, which Google describes as the primary way Chrome blocks certificates in emergencies; Chrome does not generally make online OCSP or CRL checks. Firefox uses OneCRL, introduced in Firefox 37, to push revoked intermediate certificates through its blocklist without a browser update or restart, and CRLite, which downloads a compact encoding of every revoked certificate that appears in Certificate Transparency logs, refreshes it every 12 hours and checks it locally. Mozilla turned CRLite on for desktop Firefox from version 137 and stopped OCSP checks for domain-validated certificates in Firefox 142.
Root removal. A root program can drop a root from its store, or stop trusting new certificates under it. In 2024 Chrome stopped trusting, by default, TLS certificates from a set of Entrust roots whose earliest Signed Certificate Timestamp (SCT) was after 11 November 2024, starting with Chrome 131, while leaving certificates logged before that date working. Downstream lists such as Mozilla-derived bundles follow when they are next rebuilt.
Certificate Transparency (CT). CT logs are public, append-only records of issued certificates, and browsers such as Chrome and Safari enforce that certificates are logged. This is what limits the damage from a stolen or weak CA key: a fake certificate that is not in CT is rejected by CT-enforcing browsers, and one that is logged can be seen by monitors. Clients that do not enforce CT get no such protection.
Case study: eMudhra, October 2026
On 17 October 2026 a researcher reported that the private keys of eight eMudhra intermediate CAs could be recovered. Mozilla found they were P-384 keys generated as integers smaller than 256, so anyone could derive them from the public certificates. Chrome blocked the six TLS intermediates by public key in a CRLSet within about two hours, Firefox blocked them via OneCRL the same day, and Apple followed on 19 October. Because no certificates from those intermediates were in CT logs, CT-enforcing browsers could not have been fooled. The work that took days was everywhere else: Go shipped 1.27.3 and 1.26.10 to hard-block the keys, Mozilla released NSS 3.131.1, and Ubuntu, Debian, Fedora, Alpine, the curl bundle, certifi, pip, uv, rustls and Electron each released updates on their own schedules, with Node.js and others still pending days later. On 20 October Mozilla and Chrome moved to remove the whole emSign ECC Root CA - G3, and eMudhra said about 30,000 customer certificates under it needed to move to another chain. The current status is on this desk's eMudhra card.
The two sides of a distrust event
As a relying party (your systems connect to others): the risk is that your clients keep trusting the bad CA. Browsers are usually fixed first and automatically. Your servers, scripts, agents, containers and appliances are not.
As a subscriber (others connect to you): if your own sites, APIs or device certificates chain to the distrusted CA, updated clients will start rejecting them, often with errors such as x509: no valid chains built or unable to get local issuer certificate. Certificates issued through ACME can usually be moved to another CA quickly; manually issued and pinned certificates take longer.
Runbook
1. Hear about it early. Watch the Mozilla dev-security-policy forum, the Chrome Root Program, Mozilla's Bugzilla CA incident bugs and your Linux distribution's security announcements; the ACSC and CERT advisories usually come later. Treat a CA compromise as a critical advisory (see the critical advisory intake page).
2. Know your trust stores. Keep a list of where trust decisions are made: OS ca-certificates on servers and images, language bundles (certifi, Go version, Java cacerts, Node.js, Electron), container base images, reverse proxies and load balancers, VPN and SSO appliances, and IoT or OT devices with fixed bundles. An SBOM helps find the bundled ones.
3. Block fast where you can. Apply OS and runtime updates as each lands. Where none exists yet, add the affected intermediates or root to the platform's distrust list if it has one, or remove the root from your own managed bundle. Rebuild and redeploy statically built software, because a new Go or Rust version does nothing until the binary is rebuilt. Use test hosts (the eMudhra disclosure site published some) to confirm each client now rejects the chain.
4. Check your own certificates. Use CT search or a CT monitor for your domains to list every certificate issued for them and by which CA, and replace any that chain to the distrusted CA before clients start rejecting them. Subscribe to a CT monitor so you also learn of unexpected issuance, and use CAA records to limit which CAs may issue for your domains.
5. Close the long tail. Record systems that cannot be updated (embedded devices, legacy Java, vendor appliances), ask the vendor for a fix date, and add compensating controls such as restricting where those clients can connect. Re-check a week later: downstream fixes arrive over days, and some lists are only rebuilt monthly.
Practitioner checklist
Can you answer within an hour: which of our servers, images and appliances trust a given root; which of our public certificates come from which CA; and who owns renewing them? If not, build that inventory now, before the next distrust event. Keep certificate issuance automated (ACME) wherever possible so that changing CA is a configuration change, not a project.
See also:
Fact source: Chromium — CRLSets (how Chrome blocks certificates in emergencies), Mozilla Security Blog — Revoking intermediate certificates: introducing OneCRL (2015), Mozilla Hacks — CRLite: fast, private and comprehensive certificate revocation checking in Firefox (19 Aug 2025), Google Security Blog — Sustaining digital certificate security: Entrust certificate distrust (27 Jun 2024, updated Sep 2024), Certificate Transparency — How CT works, Mozilla Bugzilla 2083449 — Private key compromise of eMudhra intermediate certificates (Oct 2026), Mozilla dev-security-policy — Compromised eMudhra intermediate certificates (Mozilla and Chrome Root Program posts, Oct 2026), eMudhra intermediate CA compromise — disclosure and downstream fix tracker (Oct 2026), curl — CA certificates extracted from Mozilla.