# When a CA Loses Its Keys: Why the eMudhra Compromise Barely Touched Browsers but Still Trusts Your curl > In October 2026 the private keys of eight eMudhra intermediate CAs were reported compromised. Browsers stopped trusting them within days through revocation (OneCRL, CRLite, CRLSets). But curl, container images, and language trust stores (certifi, Go, Rust webpki) kept trusting them until a ca-certificates update shipped. A security-leadership read of the real gap a CA compromise exposes — not whether revocation exists, but which of your clients honour it — and how to measure your own readiness. Source: https://playciso.com/blog/emudhra-intermediate-ca-compromise-revocation-vs-trust-stores · Published: 2026-10-20 · Publisher: PlayCISO (https://playciso.com) Primary source: https://www.we-have-a-problem.com/ --- A certificate authority losing control of its signing keys is one of the few events that can break trust for the entire web at once. In October 2026 it happened: a public disclosure reported that the private keys of **eight eMudhra intermediate CA certificates** were compromised. The striking thing about the response is how lopsided it was — browsers were protected in days, and a great deal of everything else was not. That gap is the real lesson for security leaders, and it has nothing to do with eMudhra specifically. _Independent, vendor-neutral analysis for security & IT leaders, based on the public disclosure at [we-have-a-problem.com](https://www.we-have-a-problem.com/) (published by Dennis Jackson). PlayCISO is not affiliated with eMudhra, Mozilla, Google, Apple, Microsoft or any certificate authority. Facts below are relayed from that disclosure and the root programs’ public actions._ What happened — in plain words The private keys of eight **eMudhra intermediate CAs** (chaining to the `emSign Root TLS CA - G3` and `AAA Certificate Services` roots) were reported compromised. A researcher proved it by signing a fixed message with each key and reporting it to the root programs on **17 October**. Anyone holding one of those keys could issue certificates **impersonating any website**. The root programs revoked trust fast — **Firefox and Chrome from 17 Oct, Apple from 19 Oct, Microsoft from 20 Oct** — through OneCRL, CRLite and CRLSets, and eMudhra revoked the certificates. But that machinery only protects clients that **consume revocation**. Most non-browser clients do not. ## Revocation is a browser feature. Your infrastructure is not a browser. The browser response worked because Mozilla, Chrome, Apple and Microsoft each ship revocation data to their users continuously — OneCRL and CRLite for Firefox, CRLSets for Chrome, and the OS tooling for Apple and Microsoft. Flag an intermediate as distrusted there and hundreds of millions of browsers stop accepting it within a normal update cycle. Now list everything that makes TLS connections and _isn’t_ a browser: your application’s HTTP client, `curl` and `wget` in scripts and health checks, container base images, reverse proxies, load balancers, API gateways, mobile apps, IoT and OT devices, CI runners. A large share of those verify a server certificate against a **static bundle of trusted CAs** and never ask whether a certificate has been revoked. To them, a compromised-but-revoked intermediate is still perfectly valid — until the bundle itself is replaced by a software update. ## The specifics that bite - Distro trust stores update on their own clock. On Debian/Ubuntu the fix is an updated ca-certificates package; other distros ship their own. Until it is installed and services pick it up, the host keeps trusting the intermediate. - Language runtimes each carry their own trust store. Python’s certifi, Go, and Rust’s rustls-webpki / webpki-roots all bundle CAs and patched on their own timelines in this incident; some components’ fixes were still pending when browsers were already protected. - Containers freeze trust at build time. A running image keeps whatever CA bundle it was built with. Patching the host does nothing for the container until it is rebuilt and redeployed. - macOS /usr/bin/curl is a quiet trap. Per the disclosure, it verifies against /etc/ssl/cert.pem and does not check revocation — so it can keep trusting a blocked intermediate even on an otherwise up-to-date Mac. None of this is exotic. It is the ordinary, sprawling reality of where TLS trust actually lives in a modern estate — and it is exactly the part no revocation feed can fix for you. ## The generic lesson: measure agility, not luck Every CA compromise re-teaches the same thing. The question is never "does revocation exist" — it does. The questions that decide your exposure are: - Inventory: do you even know which roots and intermediates you trust, and which services and clients rely on them? - Revocation consumption: which of your client types honour revocation, and which silently keep trusting until re-imaged? - Distrust agility: can you push a "stop trusting this CA" change across servers, containers, workstations and CI in hours, through configuration management and rebuilds — or does it take weeks of manual work? - Lifecycle automation: do ACME and short-lived certificates make mass re-issuance routine, so a forced rotation isn’t a fire drill? - Monitoring: are you watching Certificate Transparency logs for unexpected issuance against your domains, and have you set CAA records to constrain who may issue for you? For the authoritative patched versions and step-by-step remediation for your specific systems, follow your vendors’ and distributions’ official advisories. What we can help with is the readiness question. ## Score your own readiness We built a free, in-browser **[CA Compromise Readiness Scorecard](/tools/ca-compromise-readiness-scorecard)** around exactly these dimensions — inventory, revocation consumption, fleet-wide distrust agility, certificate-lifecycle automation, CT/CAA monitoring, pinning and incident response. Answer the questions, get a 0–100 score and an Exposed / Reactive / Resilient / CA-agile band, see your weakest areas, and export the result. It is an educational self-assessment, not an audit or legal advice — but it turns "are we exposed if a CA we trust is compromised?" from a shrug into a number and a to-do list. If PKI is part of a broader programme for you, it pairs naturally with our [Ransomware Readiness Scorecard](/tools/ransomware-readiness-scorecard) and the [IR Playbook Lab](/tools/ir-playbook-lab) — a compromised CA is, after all, just another incident you want to have rehearsed before it is real.