Google, Mozilla revoke eMudhra intermediates after private key compromise
CSO Online ·
Private keys associated with eight intermediate certificate authorities operated by Indian digital trust provider eMudhra have been compromised, potentially allowing attackers to forge trusted certificates and impersonate websites or services, according to Google and Mozilla. “On 17th October @ 20:06 UTC, Mozilla received a report to certificates@mozilla.org, forwarded by the Chrome Root program, that the private key of 8 eMudhra Intermediate certificates have been compromised,” Dennis Jackson, a member of Mozilla’s engineering team, wrote in a public Mozilla bug report . “An attacker with the private key of any of the compromised intermediate CAs could impersonate any website or service.” Mozilla independently recovered the keys later that day, confirming that they were vulnerable. “Mozilla was able to recover the private keys for the impacted certificates independently @ 21:48 UTC and without any knowledge of the method the original reporter used,” Jackson added in the report. He said the recovery confirmed that “the key generation process was flawed and is trivial to exploit.” The report was submitted by a researcher identified as Wayne and forwarded by the Chrome Root Program. Mozilla acknowledged it and subsequently began blocking the affected certificates in Firefox. eMudhra acknowledged the report and said it was investigating, according to the Mozilla report. “One of eMudhra’s certificate authority private keys is the number 4,” security researcher Scott Helme wrote in a separate analysis . Two other keys had values of 56 and 115, he said. Helme recovered all eight from their public certificates in less than a second. Six of the eight affected intermediate certificates were intended for Transport Layer Security (TLS), which browsers and applications use to authenticate websites and establish encrypted connections, according to Google’s security blog post . 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 added in the blog post. Browser blocks and enterprise exposure Google’s Chrome Root Program received a report and deployed a Chrome Revocation List Set update blocking the affected intermediate authorities, according to the company’s security blog. “Chrome users were immediately protected against all certificates sharing those keys, without requiring a browser update or restart,” Google added in the blog post. Android devices and Chromebooks also received an equivalent update through Google Play Services. Google said no TLS certificates chaining to the six affected intermediates appeared in Certificate Transparency logs before the blocking action. It said no fraudulent certificates issued by those authorities could have been used against clients enforcing Certificate Transparency, including Chrome’s default configuration. Mozilla said in its security blog post that it completed the distribution of its OneCRL block to Firefox users with standard configurations. Mozilla also announced updates for users whose custom settings might have prevented them from receiving the block. Google said it had removed the emSign ECC Root CA – G3 certificate, which signed the affected intermediates, from the Chrome Root Store. The change was scheduled to reach all devices relying on that store on October 27. Enterprise applications face separate checks Yash Kadakia, founder and CTO of Security Brigade, estimated that about 30,000 legitimate certificates would need to be migrated. He said government and public-sector websites using the affected hierarchy could face browser warnings or access disruptions if replacement certificates were 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.” Kadakia said enterprise security teams should check payment gateways, vendor integrations, older Java applications, mobile apps, and network appliances, which may use certificate trust stores separate from browsers. “Security teams need to identify both the certificates their services present and the certificate authorities their applications trust,” he said. He advised organizations to test whether affected clients reject certificates signed by the compromised keys, including cross-signed chains. Cloudflare said in its October 20 incident report that it learned of the compromise on October 19 and deployed mitigations across its content delivery network, developer services, and Zero Trust products. 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 in its report. eMudhra says no end-entity certificates were issued eMudhra, in its incident statement , said the affected intermediate authorities were created during a key-generation ceremony in April 2025. It said the incident did not affect its root CA private keys or other intermediate authorities. “None of these intermediate CAs, including the one deployed in production, have issued any end-entity certificates,” the company said. It said its internal analysis was corroborated by public Certificate Transparency records and that it was investigating the incident and reviewing its security controls. Kadakia said the absence of issued end-entity certificates was reassuring, but noted that someone holding a compromised intermediate key could generate fraudulent certificates without requesting them from eMudhra. eMudhra did not immediately respond to a request for comment.