{"id":10111,"date":"2026-10-21T10:21:14","date_gmt":"2026-10-21T10:21:14","guid":{"rendered":"https:\/\/cybersecurityinfocus.com\/?p=10111"},"modified":"2026-10-21T10:21:14","modified_gmt":"2026-10-21T10:21:14","slug":"google-mozilla-revoke-emudhra-intermediates-after-private-key-compromise","status":"publish","type":"post","link":"https:\/\/cybersecurityinfocus.com\/?p=10111","title":{"rendered":"Google, Mozilla revoke eMudhra intermediates after private key compromise"},"content":{"rendered":"
\n
\n
\n
\n
<\/div>\n

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.<\/p>\n

\u201cOn 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,\u201d Dennis Jackson, a member of Mozilla\u2019s engineering team, wrote in a public Mozilla bug report<\/a>. \u201cAn attacker with the private key of any of the compromised intermediate CAs could impersonate any website or service.\u201d<\/p>\n

Mozilla independently recovered the keys later that day, confirming that they were vulnerable.<\/p>\n

\u201cMozilla 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,\u201d Jackson added in the report. He said the recovery confirmed that \u201cthe key generation process was flawed and is trivial to exploit.\u201d<\/p>\n

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.<\/p>\n

eMudhra acknowledged the report and said it was investigating, according to the Mozilla report.<\/p>\n

\u201cOne of eMudhra\u2019s certificate authority private keys is the number 4,\u201d security researcher Scott Helme wrote in a separate analysis<\/a>. Two other keys had values of 56 and 115, he said. Helme recovered all eight from their public certificates in less than a second.<\/p>\n

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\u2019s security blog post<\/a>. The other two were for code signing.<\/p>\n

\u201cThe 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,\u201d Google added in the blog post.<\/p>\n

Browser blocks and enterprise exposure<\/h2>\n

Google\u2019s Chrome Root Program received a report and deployed a Chrome Revocation List Set update blocking the affected intermediate authorities, according to the company\u2019s security blog.<\/p>\n

\u201cChrome users were immediately protected against all certificates sharing those keys, without requiring a browser update or restart,\u201d Google added in the blog post. Android devices and Chromebooks also received an equivalent update through Google Play Services.<\/p>\n

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\u2019s default configuration.<\/p>\n

Mozilla said in its security blog post<\/a> 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.<\/p>\n

Google said it had removed the emSign ECC Root CA \u2013 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.<\/p>\n

Enterprise applications face separate checks<\/h2>\n

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.<\/p>\n

\u201cThis isn\u2019t just about eight compromised keys. It\u2019s about the global internet\u2019s chain of trust,\u201d Kadakia said. \u201cA single authority\u2019s failure can undermine authentication for organisations that have never dealt with it.\u201d<\/p>\n

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.<\/p>\n

\u201cSecurity teams need to identify both the certificates their services present and the certificate authorities their applications trust,\u201d he said. He advised organizations to test whether affected clients reject certificates signed by the compromised keys, including cross-signed chains.<\/p>\n

Cloudflare said in its October 20 incident report<\/a> 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.<\/p>\n

\u201cOur security review has not identified active exploitation of this issue on Cloudflare services,\u201d the company said in its report.<\/p>\n

eMudhra says no end-entity certificates were issued<\/h2>\n

eMudhra, in its incident statement<\/a>, 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.<\/p>\n

\u201cNone of these intermediate CAs, including the one deployed in production, have issued any end-entity certificates,\u201d 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.<\/p>\n

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.<\/p>\n

eMudhra did not immediately respond to a request for comment.<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>","protected":false},"excerpt":{"rendered":"

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. \u201cOn 17th October @ 20:06 UTC, Mozilla received a report to certificates@mozilla.org, forwarded by the Chrome Root program, that the […]<\/p>\n","protected":false},"author":0,"featured_media":10112,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-10111","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-education"],"_links":{"self":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/10111"}],"collection":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=10111"}],"version-history":[{"count":0,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/10111\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/media\/10112"}],"wp:attachment":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=10111"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=10111"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=10111"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}