Eight eMudhra CA Keys Cracked: Chrome and Firefox Block Intermediates

Eight intermediate certificate authorities run by Indian digital trust provider eMudhra had their private keys compromised, and Google and Mozilla have now blocked them in Chrome and Firefox. An attacker holding any of those keys could impersonate any website or service that still trusts the hierarchy.

The disclosure arrived on 17 October at 20:06 UTC, when Mozilla's certificates@mozilla.org inbox received a report forwarded by the Chrome Root Program from a researcher identified only as Wayne. Dennis Jackson, a member of Mozilla's engineering team, wrote in a public bug report: "An attacker with the private key of any of the compromised intermediate CAs could impersonate any website or service."

Mozilla did not take the report on faith. Jackson's team recovered the private keys independently at 21:48 UTC the same day, without knowing the original reporter's method. That recovery, he wrote, confirmed "the key generation process was flawed and is trivial to exploit." eMudhra acknowledged the report and said it was investigating.

How weak were the keys?

Weak enough to embarrass a certificate authority. Security researcher Scott Helme recovered all eight private keys from their public certificates in less than one second. One key, he noted in his analysis, had the value 4. Two others carried the values 56 and 115. This is not cryptanalysis; it is arithmetic.

Six of the eight affected intermediates were intended for TLS, the protocol browsers and applications use to authenticate websites and establish encrypted connections, according to Google's security blog. The other two were for code signing.

"The private keys for these certificates were generated with insufficient randomness (i.e., weak cryptographic entropy), enabling anyone to forge trusted HTTPS certificates to impersonate any website against clients that have not yet removed trust in those CAs," Google said.

What did the browser vendors deploy?

The Chrome Root Program pushed a Chrome Revocation List Set update blocking the affected intermediate authorities. "Chrome users were immediately protected against all certificates sharing those keys, without requiring a browser update or restart," Google said. Android devices and Chromebooks received an equivalent update through Google Play Services.

Google also removed the emSign ECC Root CA – G3 certificate, which signed the affected intermediates, from the Chrome Root Store. That change was scheduled to reach all devices relying on the store on 27 October.

Mozilla completed distribution of its OneCRL block to Firefox users with standard configurations and issued additional updates for users whose custom settings might have blocked delivery.

Google found no TLS certificates chaining to the six affected intermediates in Certificate Transparency logs before the blocking action. By its account, no fraudulent certificate from those authorities could have been used against clients enforcing CT, including Chrome's default configuration.

What does this change for enterprises?

Roughly 30,000 legitimate certificates will need migration, according to Yash Kadakia, founder and CTO of Security Brigade. Government and public-sector websites using the affected hierarchy could face browser warnings or access disruptions if replacement certificates are not installed in time.

"This isn't just about eight compromised keys. It's about the global internet's chain of trust," Kadakia said. "A single authority's failure can undermine authentication for organisations that have never dealt with it."

His checklist for security teams is concrete:

• Check payment gateways and vendor integrations for affected chains
• Audit older Java applications, mobile apps, and network appliances, which often carry trust stores separate from browsers
• Test whether affected clients reject certificates signed by the compromised keys, including cross-signed chains

"Security teams need to identify both the certificates their services present and the certificate authorities their applications trust," he said.

Cloudflare learned of the compromise on 19 October and deployed mitigations across its CDN, developer services, and Zero Trust products, according to its 20 October incident report. It also updated shared trust stores and base images and released updates for Cloudflare One clients and Cloudflare Tunnel. "Our security review has not identified active exploitation of this issue on Cloudflare services," the company said.

Did eMudhra issue anything from the broken intermediates?

The company says no. In its incident statement, eMudhra said the affected intermediate authorities were created during a key-generation ceremony in April 2025, and that the incident did not touch its root CA private keys or other intermediates.

"None of these intermediate CAs, including the one deployed in production, have issued any end-entity certificates," the company said, adding that its internal analysis was corroborated by public Certificate Transparency records. It continues to investigate and review its security controls.

Kadakia called the absence of issued end-entity certificates reassuring, with one caveat: anyone holding a compromised intermediate key could generate fraudulent certificates without ever asking eMudhra. eMudhra did not immediately respond to a request for comment.

For CIOs, the practical task is inventory. Count what you present, list what you trust, and patch the trust stores browsers never see.