Mozilla and Chrome Distrust eMudhra's emSign ECC Root CA – G3: How a 30 April 2025 Key Ceremony Produced Eight Recoverable P-384 Keys and Ended in eMudhra's 22 October 2026 Exit From Global TLS
In May 2008 Debian published security advisory DSA-1571. Two years earlier a well-meant change to Debian's OpenSSL package had removed almost all of the randomness from its random-number generator, so every key it created came from a list of about 32,000 possibilities per key type and size. The keys looked normal, and the signatures they made verified. For nearly two years nobody checked the one property that mattered, which was whether the secret part was hard to guess.
Eighteen years later the same blind spot has cost a certificate authority a browser root. The eMudhra case moved from report to distrust in under four days, and nearly every step of it is public in Mozilla's Bugzilla entry 2083449.
What the researcher reported to Apple, Google, Microsoft and Mozilla on 17 October 2026
According to the timeline the reporter posted in the bug, a run of new analysis tools over the public list of trusted certificate authorities found a break in eMudhra's elliptic-curve keys at 16:27 UTC on 17 October. At 18:05 UTC he emailed the Apple, Chrome, Microsoft and Mozilla root programs and eMudhra, with a signed attestation for each key. Mozilla logged the report at 20:06 UTC and confirmed that the proof of key control was valid. At 21:48 UTC it had recovered the private keys itself, "without any knowledge of the method the original reporter used." By 22:59 UTC a OneCRL update blocking the eight intermediates had reached Firefox users with standard settings.
Six of the eight certificates were TLS intermediates trusted by all four browser root programs. The other two were code-signing intermediates trusted by Microsoft. Sectigo had cross-signed some of them and revoked those cross-certificates on 19 October.
How eight P-384 keys below 256 came out of the 30 April 2025 ceremony
Mozilla's engineer Dennis Jackson set out the technical finding in comment 5 of the bug. The eight keys were part of a batch of 24 intermediates created on 30 April 2025, split across three series, two key types (RSA-4096 and P-384) and four purposes. Every P-384 key in the B and C series was affected. A P-384 private key should be a random integer between 1 and a number with 116 decimal digits. These eight were all smaller than 256: "effectively all-zeroes apart from the last byte." Anyone could recover them by generating the first 256 keys and comparing. Jackson added that local AI agents he tested recovered a key on the first attempt from a one-line prompt. He could not recover the P-384 keys of the A series or its replacement despite much more effort.
eMudhra's public status page gives the company's account. The keys were generated on FIPS 140-2 Level 3 certified hardware security modules, and "a key wrap/unwrap step produced a second, weak set of keys alongside the original strong keys. The weak keys were the ones published to the browser root stores." The company says the root cause is not yet confirmed and that the issue "went undetected for about 18 months, through two independent audit cycles." Those audit cycles are eMudhra's own description. The audit reports and their dates were not part of the public bug record when this post was written.
Practical takeaway. The certificates involved carried valid signatures, came from hardware eMudhra describes as FIPS-validated and, by eMudhra's account, passed two audit cycles. On the company's preliminary explanation the fault lay in the value of the published secret, and nothing in the public file shows a check on that value before the researcher's. He needed public data and under half an hour, by his own timeline.
There was an earlier signal. In June 2025 Bugzilla entry 1970728 recorded that eMudhra had published revocation lists for the same six TLS intermediates with invalid signatures. That bug was closed as fixed. Jackson wrote that it "seems unlikely that the exact same intermediate set has arisen in two different bugs by chance."
Why Mozilla and Chrome announced the removal of the whole emSign ECC Root CA – G3 on 20 October 2026
Revoking an intermediate protects only clients that check revocation. Many servers, phones, appliances and embedded systems never do. On 20 October Mozilla wrote in comment 18 that "multiple individuals have independently recovered the private keys," some of them publicly. After talking with downstream users of its root store, it announced the emergency removal of trust in emSign ECC Root CA – G3, which "will protect clients which do not use revocation information." It asked eMudhra to stop issuing from every intermediate under that root. It did not remove eMudhra's separate emSign Root CA – G1. The Chrome Root Program committed to "a similar path" the same afternoon and set out its plan in the Mozilla dev-security-policy forum. Mozilla's Security Blog post of 20 October describes the OneCRL block, the unscheduled Firefox releases that carried it to users whose settings had stopped the update, and the removal of the root from NSS 3.131.1, the trust store other applications draw on. Blocking the intermediates took effect on 17 October. Removing the root takes effect as each trust store ships its update; Chrome wrote in comment 30 that it expects Chrome Root Store v43, without the root, to reach Chrome Stable on 27 October.
Who has to replace certificates: about 30,800 chains, most of them issued through InCommon for US universities
None of the eight broken intermediates had issued a single customer certificate, as eMudhra and public Certificate Transparency logs both show. The cost of distrust falls on the healthy certificates under the same root. The Chrome Root Program counted, in comment 30, about 30,800 unexpired precertificates chaining to emSign ECC Root CA – G3 as of 21 October. 99.9% of them came from two subordinate CAs operated for Internet2's InCommon, the trust federation that serves American universities and research institutions. eMudhra's status page describes the impact as "contained to a single customer ecosystem in the United States." That ecosystem includes campus portals, library systems, research data services and teaching platforms, and their administrators now have to move tens of thousands of certificates to another chain before browsers stop accepting them. Chrome's comment also asked eMudhra to name the affected root and intermediates on its own pages and to tell subscribers how to check whether they are affected, information it said neither of eMudhra's public documents then contained.
On 22 October eMudhra announced that its board had decided to "voluntarily withdraw from the global SSL/TLS certificate business," which it put at about 1% of global revenue. Its G1 RSA roots will keep serving customers through the transition, replacement certificates will come "free of cost from partners," and it says it will still deliver a full root-cause report to the root programs. Its digital-signature, eSign and identity businesses, including those in India, are not affected.
How Quentir Reads It
The eMudhra case is the clearest public example so far of a failure class that matters for the post-quantum transition. That transition brings new key generation into the Web PKI. Some root programs and CAs will key new hierarchies for ML-DSA, the lattice signature standard NIST published as FIPS 204; others are working on different structures, such as the Merkle Tree Certificates route; algorithms and hierarchies will differ by root program. Wherever new CA keys are made, they come out of ceremonies with new HSM firmware, new scripts, new wrap and backup steps and staff doing them for the first time. eMudhra's keys came through the familiar assurance layers: a validated module, by eMudhra's description, an audit regime and a documented ceremony. Section 6.1.1.1 of the CA/Browser Forum Baseline Requirements requires a key generation script, a Qualified Auditor's witness or a video, and an auditor's report for root keys and for subordinate CAs run by unaffiliated operators; for intermediates run by the root's own company or its affiliates, as these were, the script and witness are a SHOULD. In all cases it requires a secured environment, multi-person control, suitable cryptographic modules and logging. Section 6.1.1.3 obliges a CA to reject a subscriber's key known to be weak and names the Debian keys explicitly. The section on the CA's own key pairs contains no comparable test of the key value. eMudhra's preliminary explanation points to one procedural step around the module, a wrap/unwrap test; the exact cause, the module firmware and its operating mode are still open questions in the bug. A targeted check for trivially small private keys would have flagged these eight at once.
Two features of the case deserve attention beyond PKI. Discovery was fast and cheap: one researcher, public data and an afternoon, and Mozilla's note that local AI agents repeated the recovery from a one-line prompt. Debian's error waited nearly two years for a specialist; this one took under half an hour once someone ran the right tool over public data. Enforcement came from browser root programs with no statute behind them. Within five days they had blocked the intermediates and announced the removal of a root, and a listed company had announced its exit from the market, citing the incident and the scrutiny that followed. Quentir's September read of Cloudflare's plan to become a public certificate authority showed the same root programs setting the terms for quantum-resistant certificates, and ePrint 2026/2131 showed a hardware security module yielding forged signatures through an interface its operators had switched on. Quentir's Signature Report No. 2, the PQC Migration Roadmap, sets the finalized NIST standards (FIPS 203, 204 and 205), the EU and US regulatory calendar and a four-phase, dated migration roadmap in one document, the frame into which re-keying a certificate hierarchy fits. The next marker in this case is eMudhra's root-cause report, which should say what the wrap/unwrap step did and whether the auditors were shown the June 2025 revocation-list fault.
Sources: Mozilla, Bugzilla 2083449, "eMudhra: Private key compromise of Intermediate Certificates", opened 18 October 2026, comments 0 to 37 read 22 October 2026; CA/Browser Forum, Baseline Requirements for TLS Server Certificates, sections 6.1.1.1 and 6.1.1.3, read 22 October 2026; Mozilla, Bugzilla 1970728, "eMudhra: Invalid CRL signatures", opened 5 June 2025; Mozilla Security Blog, "Protecting Firefox users following the compromise of eMudhra intermediate certificates", 20 October 2026; Chrome Root Program, post in the Mozilla dev-security-policy forum, 20 October 2026; eMudhra, "eMudhra Statement on Recent Certificate Security Incident", first published 20 October 2026, updated 22 October 2026; eMudhra, "eMudhra to Exit global SSL/TLS Certificate Business", 22 October 2026; Debian, DSA-1571-1, "openssl — predictable random number generator", 13 May 2008.
Published intelligence, built to inform your own decisions. Published: October 22, 2026.