eMudhra's eight intermediate CA keys were recovered; Mozilla is removing trust in their root
Eight eMudhra intermediate CA keys are trivially recoverable. Mozilla is removing trust in their root, emSign ECC Root CA - G3; bundled CA lists need updates.
eMudhra Limited is a Bengaluru-based certificate authority (CA). On October 17, 2026, Mozilla received a report that the private keys behind eight of eMudhra’s intermediate certificates had been compromised, which would let an attacker issue HTTPS certificates for sites they do not control. Mozilla’s own engineers then recovered the same keys independently. The flaw is in key generation: a P-384 private key should be a large random integer, but all eight of these are below 256.
Key points
- eMudhra’s eight private keys can be recovered almost instantly. Ars reports the integers as 4, 56, 66, 115, 155, 156, 230 and 237. Researcher Scott Helme says he recovered all of them from public certificates on a laptop in less than a second.
- Browsers blocked first; other trust stores have to catch up. Mozilla is removing trust in emSign ECC Root CA - G3, the root that signed the intermediates, through NSS 3.131.1. Chrome says it will take a similar path.
- About 30,000 certificates need to move. eMudhra says roughly 30,000 certificates chain to that root, about 97% of them issued over ACME. Subscribers will move to intermediates under G1, an RSA root.
Background
The eight certificates came from a single key ceremony on April 30, 2025. That batch held 24 intermediates in three series, A, B and C, across RSA and P-384 key types. According to Mozilla’s investigators, every P-384 key in the B and C series is affected. The A series was revoked in May 2025 and replaced by the A-1 series. Some affected intermediates were cross-signed by Sectigo, which finished revoking them on October 19.
Mozilla’s investigators also found a related problem in bug 1970728, where eMudhra had generated CRLs for six of the TLS intermediates with invalid signatures. Reading an Internet Archive snapshot, they concluded those CRLs had failed verification since May 23, 2025, but they call that finding preliminary. In an October 21 statement, eMudhra says its roots and issuing CAs passed independent audits for two consecutive years and have been in browser trust lists since mid-2025.
The facts
eMudhra’s timeline, in UTC:
| Time | Event |
|---|---|
| Oct 17, 20:06 | Mozilla receives a report, forwarded by the Chrome Root Program, with proof of control for all eight keys |
| Oct 17, 22:59 | Firefox’s OneCRL block finishes rolling out to standard configurations |
| Oct 18, 09:38 | eMudhra revokes the eight certificates with reason caCompromise |
| Oct 19, 14:55 | Sectigo completes revocation of its cross-signed CA certificates |
| Oct 20, 13:06 | Mozilla announces emergency removal of trust in emSign ECC Root CA - G3 |
| Oct 20, 14:16 | eMudhra says it will immediately stop issuing from every intermediate under that root |
| Oct 20, 19:20 | Cloudflare finishes deploying CDN and server-side Zero Trust mitigations |
Six of the eight are TLS certificates trusted by the Chrome, Mozilla, Microsoft and Apple root programs. The other two are code-signing certificates trusted by Microsoft. eMudhra says none of these intermediates issued end-entity certificates, and that the keys were generated in Ultimaco hardware security modules. In a bug comment dated October 19, eMudhra gave a preliminary root cause: during an approved deviation from its usual key-generation procedure, meant to test a wrap/unwrap step, a second, weaker key pair was generated. Because the key labels were similar, that pair was mistakenly used to create a certificate signing request (CSR) that its root signed, and the CSR was also sent to Sectigo for cross-signing. eMudhra also says the KGC script appears to be flawed and that human errors occurred at several steps. The full root cause is still under review. The test site says Certificate Transparency logs hold no entries for these intermediates since April 2025, so browsers that enforce CT could not have been attacked. It also concedes that many clients outside the browser ecosystem do not enforce CT, and says it does not know whether attackers exploited the keys.
Trust stores are handling the fix differently:
| Project | Change |
|---|---|
| Firefox and NSS | Firefox 158.0.1, ESR 115.43.1 and ESR 153.5.1 shipped on October 20 for users whose custom settings may have blocked the OneCRL update. NSS 3.131.1 removes the root |
| Rust webpki-roots | Version 1.0.10, released October 19, removes emSign ECC Root CA - G3 |
| Python certifi | An October 18 commit removes the emSign roots; an October 20 commit restores the unaffected ones. PyPI lists versions 2026.10.18 and 2026.10.19 |
| Go | Versions 1.27.3 and 1.26.10, released October 19, include crypto/x509 security fixes. The release notes do not name eMudhra, and their link to this incident is unconfirmed |
What others say
Cloudflare’s October 20 post says it learned of the problem around 17:00 UTC on October 19, patched critical services first, and has found no active exploitation on its own services. It argues browsers can fix this “with a flip of a switch” through fast revocation mechanisms such as Chrome’s CRLSets, while operators have hundreds of applications to update. It also warns against disabling certificate verification when errors appear after patching, because that removes the protection the update restores.
iTnews tested the command line. Juha Saarinen found that curl on macOS still accepted the compromised chain, even though Apple had blocked it. Curl checks certificates against its own CA file, /etc/ssl/cert.pem on macOS, and does not consult revocation data. iTnews relays a suggestion from Mozilla’s Dennis Jackson to remove emSign ECC Root CA - G3 and Sectigo’s AAA Certificate Services from that file. Mozilla later clarified in the bug that AAA Certificate Services is not in its root store, so it needs no OneCRL entry.
Platform timing is inconsistent. Jackson’s test site says Firefox and Chrome blocked the certificates from October 17, Apple devices from the 19th, and Microsoft platforms from the 20th. Ars reported that Edge on Windows 10 was still connecting to 12 vulnerable hosts, and a Microsoft representative said only that the company would get in touch if it had anything to share. No official Apple notice turned up; the Apple timing comes from the test site and iTnews.
Filippo Valsorda, a cryptography maintainer for Go, told Ars this will be “a massive cleanup job, bigger than Heartbleed.” He pointed to a long tail of IoT devices, Docker containers, forgotten Linux machines and command-line tools that ship their own copy of the roots. Valsorda also reimplemented the NIST curve seed algorithm in Go, which we covered in our NIST curve seeds story. Ars adds a caveat: exploiting these certificates requires an active man-in-the-middle position, which is far easier for someone controlling a coffee-shop or university network.
The Hindu BusinessLine reported that on October 21 eMudhra’s shares were down 20 percent, at Rs 432, on the National Stock Exchange of India, and CNBC-TV18 reported the same price. In a statement issued that day, eMudhra said its infrastructure was not compromised and no data was breached. It put the affected global TLS business at about 1 percent of its revenue, and said it is contacting customers who may be affected to provide replacement certificates, coordinating with root programs and continuing its root-cause investigation. The Register said eMudhra had not answered its questions at the time of writing.
Our take
For people who write software, the question is less whether browsers are fixed than where a program’s trust comes from. Python’s certifi, Rust’s webpki-roots, container base images and CA files bundled with applications each decide what to trust, and each has to be fixed on its own. A passing browser test does not show that a background service is safe, as Cloudflare points out.
Of the roughly 30,000 certificates that must move, about 97 percent were issued over ACME. We think most of those renew automatically, so this part of the migration should be easier than it would be for hand-issued certificates. That fits the direction of Let’s Encrypt’s move to 64-day certificates: the more renewal is automated, the less a root change depends on people.
Several things remain open. Mozilla has not recovered the keys in the A and A-1 series and has not checked the RSA keys yet, and it calls its findings preliminary. eMudhra says its RSA issuers followed a different path and are unaffected. Its full root cause is still under review, and it says it will reverify every key ceremony it has run. The Microsoft timeline also conflicts, so anyone relying on Windows should test rather than assume. The longer lesson is that each application keeps its own static list of trusted roots. Cloudflare argues trust stores need to take in revocation and CT information quickly, not just add and remove roots. For unmaintained long-tail software, there is no ready fix.
How to try it
The test site at emudhra.we-have-a-problem.com shows whether your browser still trusts these intermediates. Command-line users can run curl https://dv-g3b-emudhra.we-have-a-problem.com/. The site says a certificate error means the client no longer trusts the compromised intermediate. A second host, dv-g3b-aaa-emudhra.we-have-a-problem.com, works the same way. When we wrote this, we ran both commands on a Mac with curl 8.7.1. Both returned HTTP 200 and passed verification. Both certificates were issued by EM DV TLS CA - G3B, one of the compromised intermediates, so curl on that machine still accepts the chain, matching iTnews’s test. A test covers only the path it exercises, so check your application through its own TLS stack.