Mozilla and Chrome block eight compromised eMudhra CA keys

Mozilla and Google’s Chrome Root Program confirmed on Oct. 20 that private keys for eight eMudhra intermediate CA certificates in their trust stores are compromised, meaning anyone holding a key could issue a fraudulent certificate accepted by browsers for any website.

Six are TLS intermediates – EM DV TLS CA – G3B and G3C, EM OV TLS CA – G3B and G3C, and EM EV TLS CA – G3B and G3C – and the remaining two, EM OV CS CA – G3B and G3C, sign code. eMudhra, an Indian certificate authority selling emSign-branded certificates through firms in India, the United States, and the Netherlands, revoked all eight certificates.

A researcher told the root programs about the compromise in the evening of Oct. 17. Chrome’s root program saw the report at 18:05 UTC and finished pushing its CRLSet block list to Chrome installations for the six TLS intermediates by 19:45 UTC. Mozilla received the report at 20:06 UTC and pushed its OneCRL blocklist to Firefox installations with standard settings by 22:59 UTC; those users received the block without updating or restarting. Other trust stores learned of the block on Oct. 19; Apple acted on Oct. 19 and Microsoft on Oct. 20.

The Chrome Root Program said no TLS certificate for the six website intermediates appeared in Certificate Transparency logs – public records of newly issued certificates – before its block, and browsers requiring CT logging, including Chrome, could not have trusted those certificates by default. Certificate Transparency logs show no sign the compromised keys have been used maliciously. A second certificate sharing each key exists, cross-signed by Sectigo under its AAA Certificate Services root, and Chrome matches public keys rather than certificates when blocking, so Chrome catches those copies too. Chrome and Firefox stopped trusting Sectigo’s AAA Certificate Services root for websites in April 2025, but the root remains in Apple’s root list for iOS 26 and macOS 26, published in December 2025.

Mozilla credits only one researcher, Wayne, who signed each of the eight keys with the message “We have a problem here – Wayne”. Dennis Jackson, a Mozilla cryptography engineer, published the signatures and certificates on a one-page site at emudhra.we-have-a-problem.com. How the keys left eMudhra, when they left, and whether anyone besides the researcher holds them remain unknown.

Go blocked all eight keys in its Oct. 20 security releases, handling the fix on its URGENT track without naming the certificate authority. Go project maintainers urged immediate upgrades to versions 1.27.3 and 1.26.10, saying they “highly recommend” the patched releases. The fix reaches a Go program only after it is rebuilt with the new release, and Go 1.25 and older receive no fixes because they are out of support.

Go binaries and tools that rely on Python’s certifi root bundle check TLS certificates but do not check revocation data, trusting a chain until code or the root bundle changes. A filter in Go’s standard library rejects any chain containing one of the eight keys on Go’s verifier and on macOS and Windows system-verifier paths, and Go’s code contains eight hash values matching the eight certificates.

Mozilla removed emSign ECC Root CA – G3 from its NSS trust store on Oct. 20, and Chrome plans to remove it in version 43 of its root store. Chrome is also reviewing eMudhra’s other root, emSign Root CA – G1. The certifi, webpki-roots, and Homebrew ca-certificates bundles no longer include emSign ECC Root CA – G3, and Homebrew additionally removes the Sectigo AAA Certificate Services root and emSign Root TLS CA – G3.

A 2011 breach at Dutch certificate authority DigiNotar led browser makers to revoke trust in its certificates, and in 2017 Google, Mozilla, and other browser makers objected to Symantec’s chronic certificate mis-issuance before Symantec sold its CA business to DigiCert. Google announced in 2025 that it would stop trusting certificates from Chungwa and Netlock over concerns about operational integrity. Chrome applied the same key-matching block mechanism to rogue certificates for Google domains.

Filippo Valsorda, who maintains the cryptography packages in Go’s standard library, called the cleanup a massive job bigger than Heartbleed, citing internet-of-things devices, Docker containers, forgotten Linux machines, and unmaintained command-line tools as part of the long tail. Updating Linux distributions and embedded and internet-of-things devices will be hard and time-consuming, so the threat remains far from over.

Mozilla does not believe the problem affects other certificate authorities, and Chrome said it checked every other CA certificate in its store without finding other instances of this failure mode. Mozilla said it is investigating the root cause with eMudhra and other root programs, and will share more when it can. As of Oct. 20, eMudhra’s trust-services repository carried no notice of the incident, and Go’s public advisory does not name the authority. Chrome plans to work with Certificate Transparency log software maintainers and operators to reject certificates that chain to the compromised intermediate authorities going forward.

Mozilla advises trust store operators to block the eight intermediates now where possible, or otherwise consider removing trust in the roots that signed them. Dennis Jackson said users should update their operating systems and browsers to the newest versions as quickly as possible. Firefox installations with standard settings need no action unless Remote Settings is off or blocked on the network, and the Oct. 20 releases carry the block list. Servers that do not move to new certificate chains will become unavailable to users relying on affected trust lists.