Weak eMudhra Certificate Keys Prompt Browser Blocks and Enterprise Checks

Researchers recovered the private keys for eight eMudhra intermediate certificate authorities from public certificates, exposing how weak key generation can undermine trust across browsers, services, and enterprise software. Google and Mozilla moved to block the affected authorities; organizations also need to check systems that rely on their own certificate stores.

Eight keys, recovered from public certificates

Mozilla received a report on October 17 at 20:06 UTC, forwarded by the Chrome Root Program, that the keys had been compromised. Mozilla engineer Dennis Jackson said an attacker holding any of them could impersonate websites or services. Mozilla independently recovered the keys at 21:48 UTC, confirming that the key-generation process was flawed and, in Jackson’s words, “trivial to exploit.”

The original report came from a researcher identified as Wayne. Security researcher Scott Helme later reported that one key was the number 4, while two others were 56 and 115. Helme said he recovered all eight keys from their public certificates in less than a second.

Six affected intermediates were intended to issue TLS certificates, which authenticate websites and help establish encrypted connections. The remaining two were for code signing. Google attributed the exposure to insufficient randomness: anyone with the keys could create trusted HTTPS certificates for clients that still trusted the affected authorities.

Browser protections and their limits

Chrome’s Root Program distributed a revocation list update that blocks certificates using the compromised keys. Google said Chrome users received protection without a browser update or restart; Android devices and Chromebooks received an equivalent change through Google Play Services.

Google said Certificate Transparency logs showed no TLS certificates issued by the six affected intermediates before the block. It added that clients enforcing Certificate Transparency, including Chrome’s default configuration, would have rejected fraudulent certificates from those authorities.

Mozilla completed distribution of a OneCRL block for Firefox users with standard settings and announced updates for users whose custom configurations might prevent them from receiving it. Google also removed the emSign ECC Root CA – G3, which signed the affected intermediates, from the Chrome Root Store. That change was scheduled to reach devices relying on the store on October 27.

These browser protections don’t cover every application. Enterprise systems may use separate trust stores, leaving payment gateways, vendor connections, older Java applications, mobile software, and network appliances with different exposure.

Service providers and internal systems

Yash Kadakia, founder and CTO of Security Brigade, estimated that about 30,000 legitimate certificates would need to be migrated. He warned that sites using the affected hierarchy could encounter browser warnings or access disruptions if they didn’t install replacement certificates in time.

“This isn’t just about eight compromised keys. It’s about the global internet’s chain of trust,” Kadakia said. He advised security teams to inventory both the certificates their services present and the authorities their applications trust, then test whether affected clients reject certificates signed by the compromised keys, including cross-signed chains.

Cloudflare said it learned of the compromise on October 19 and applied mitigations across its content delivery network, developer services, and Zero Trust products. The company updated shared trust stores and base images, and issued updates for Cloudflare One clients and Cloudflare Tunnel. “Our security review has not identified active exploitation of this issue on Cloudflare services,” it said.

eMudhra says the intermediates issued no certificates

eMudhra said the affected intermediates were created during a key-generation ceremony in April 2025. The company stated that its root CA keys and other intermediate authorities weren’t affected, and that none of the eight intermediates had issued end-entity certificates, including the one deployed in production. It said public Certificate Transparency records supported its internal analysis and that it was investigating the incident and reviewing its security controls.

The lack of certificates issued through eMudhra limits what the public record shows, but it doesn’t remove the risk from the exposed keys: anyone holding one could create certificates independently. The practical next step for organizations is to verify that browsers, applications, and managed devices all reject the affected authorities.