Browsers block eight eMudhra intermediate CAs after their private keys are exposed
A researcher reported on October 17 that the private keys of eight eMudhra (emSign) intermediate CAs, six for TLS and two for code signing, were exposed (later found to be trivially weak). Chrome and Firefox blocked them within hours; Apple, Microsoft and Go followed, and Mozilla is removing the emSign ECC root.
Mozilla said on October 20 that the private keys of eight intermediate certificate authorities run by eMudhra, the Indian CA that sells under the emSign brand, had been compromised. A researcher reported it on Saturday, October 17; Chrome blocked the six TLS intermediates through CRLSet at 19:45 UTC and Mozilla pushed a OneCRL block to Firefox by 22:59 UTC. The other two are code-signing CAs. Apple blocked the certificates on October 19 and Microsoft on October 20, according to The Hacker News. Mozilla's NSS 3.131.1 removes the emSign ECC Root CA - G3 that issued the TLS intermediates, Go 1.27.3 and 1.26.10 reject chains containing any of the eight keys, and the intermediates also exist as Sectigo cross-signed copies. At publication, eMudhra had not said how the keys were exposed.
Why it matters
A CA key is an identity factory: whoever holds it can mint a certificate that proves to a client it is talking to any domain, or that code came from any publisher. Chrome found no TLS certificate from these intermediates in Certificate Transparency logs, so browsers that require CT were not exposed. Most other software is less protected.
Go binaries and anything built on Python's certifi bundle do not check revocation, so they keep trusting these chains until rebuilt or until their root bundle updates. Rebuild Go services on the fixed releases, update certifi (2026.10.19), Rust webpki-roots and OS trust stores, and inventory where your own PKI clients pin or bundle roots. If you buy certificates from eMudhra, plan to move chains now, since root removal also breaks legitimate certificates. Teams that already automate certificate lifecycle work can swap issuers in days rather than weeks.
Update, October 28, 2026: The keys appear to have been weak rather than stolen. All eight private key values were below 256, so the researcher could compute them almost instantly, The Hacker News reported on October 22. eMudhra says its systems were not breached and it never issued certificates from the eight intermediates. Its board decided to exit the global TLS certificate business and replace affected customers' certificates with free ones from partners. Chrome counted about 30,800 unexpired certificates chained to the emSign ECC root, 99.9% of them issued through InCommon, and was due to stop trusting that root on October 27. eMudhra estimates about 97% of the certificates to move were issued with ACME, which is what makes a forced migration of that size feasible.
Source: Mozilla Security Blog
Related on Start with Identity
- BlogCertighost lets any domain user forge a Domain Controller certificate
A low-privileged Active Directory account, no admin rights required, can now obtain a certificate for a Domain Controller and DCSync the krbtgt secret. Microsof
- BlogCisco buys Astrix Security for a reported 400 million dollars
Astrix goes into Duo, Splunk, and Cisco Identity Intelligence. The pitch is extending zero-trust principles to an agentic workforce, which in practice means gov
- BlogCyera agrees to buy Oasis Security for about 1 billion dollars
A data-security company is paying roughly 1 billion dollars, about 700 million of it in cash, for a four-year-old non-human identity startup. The price says mor
- PodcastSectigo
Short, frequent episodes on PKI, certificate policy, and post-quantum migration from two certificate industry veterans at Sectigo. 670 episodes and counting.
- GlossaryACME (Automated Certificate Management Environment)
ACME (Automated Certificate Management Environment) is the IETF protocol, [RFC 8555](https://www.rfc-editor.org/rfc/rfc8555) (March 2019, Proposed Standard), th
- GlossaryCertificate Authority (CA)
A certificate authority (CA) is the trusted party in a [PKI](/glossary/pki/) that verifies a requester's identity or control of a name and then signs an [X.509]