What Two Years of Audits and Hardware Keys Did Not Prove in the eMudhra Failure
eMudhra says its roots and issuing CAs passed two years of independent audits and that its keys were made in hardware. Their private keys could still be worked out from public data.
An intermediate CA signs the certificates that websites present. In mid-October, a researcher found that the private keys behind eight intermediate certificates issued under eMudhra, an Indian company, could be worked out from the public certificates. Browsers blocked the affected keys within hours.
The useful question for companies that buy security is what the assurances around those keys actually proved. eMudhra says its roots and issuing authorities passed independent audits two years running, and that the keys were generated in hardware security modules certified to FIPS 140-2 Level 3. Neither claim stopped the keys from being weak.
What the Hardware and Audits Were Meant to Guarantee
According to The Hacker News, which summarises eMudhra's 21 October stock exchange filing, the eight intermediates were created on 30 April 2025 in a key-generation ceremony run on hardware security modules. The filing attributes the problem to a flaw in a key wrap and unwrap step. That flaw produced a second, weak key set alongside the intended strong keys, and the weak keys reached the browser root stores.
In eMudhra's account, as quoted by researcher Scott Helme, a bug in the ceremony script led to a second weak key pair being created on the HSM.
The audits are the other half of the claim. eMudhra says its roots and issuing CAs passed independent audits two years in a row and have been in browser trust lists since mid-2025. Reports so far do not say what the audits tested or whether they covered the April 2025 ceremony. Those are the points a buyer can ask a provider to answer in writing.
Keys Recovered in Under a Second From Public Data
Helme says he recovered all eight private keys from their public certificates on a laptop in under a second. Each key is a small number, so the method was to compute multiples of the curve's base point, one step at a time, until the result matched the public key. No key needed more than 255 steps.
A P-384 key should be a random 384-bit number. The eight keys instead had 47 bytes of zeros followed by a single byte, with values such as 4, 56 and 115. Helme writes that the keys were effectively public from the day the certificates were issued, and that the exposure window ran for 17 months.
Helme also reports that an AI agent, which he identifies as Claude, recovered the keys from a single prompt. Helme says nobody had to steal anything.
The standard checks passed. Helme writes that every structural check passes and that the only way to find out is to try the computation.
Where the Accounts Still Disagree
The accounts of cause differ. The Hacker News describes a key wrap and unwrap flaw. Google's Chrome and Android post describes weak entropy, meaning the keys lacked enough randomness. Helme's quotation of eMudhra's update points to a script bug and to similar key names that led to the wrong keys being used for a certificate request. Root-cause work is still open, and these descriptions have not been reconciled.
Chrome and Helme give different counts. Chrome says there were eight subordinate CAs, six of them TLS-issuing and two for code signing. Helme says Mozilla attached the affected certificates to its announcement and that he pulled 16 of them, with each key used in two issued certificates, one from eMudhra and one from Sectigo.
According to The Hacker News, eMudhra's 20 October statement says only one of the eight was deployed in production and that none issued an end-entity certificate. Helme describes each key as used in two issued certificates, while eMudhra says none of the eight issued an end-entity certificate, so whether any site received a certificate from these keys remains unresolved.
“Every structural check passes. The only way to find out is to try.”
The Timeline That Matters for Trust Decisions
Chrome received the report at 18:05 UTC on 17 October and pushed a block by public-key hash at 19:45 UTC, reaching users without a browser update. Mozilla received its report at 20:06 UTC, and its block reached standard Firefox installs by 22:59 UTC. Android devices received an equivalent update through Google Play Services around 22:00 UTC on 19 October.
On 20 October, Mozilla released Firefox 158.0.1 and NSS 3.131.1 and removed the root that signed the affected intermediates. Chrome's removal of emSign ECC Root CA - G3 is expected to reach devices on Tuesday 27 October, Pacific time. Chrome says website operators whose certificate chains to that root must install a certificate from another hierarchy.
Certificate Transparency offers a partial answer on exposure. The Chrome Root Program says no TLS certificate chaining to the six TLS intermediates was logged before the block, so none could be trusted by default. Helme notes that such logs detect misissuance but do not prevent it. Whether anyone used the keys before 17 October is not known.
What Buyers of Certificates Should Check Now
Three checks follow from the record. The first is the issuing intermediate on each certificate in use, and whether it chains to emSign ECC Root CA - G3, the root Chrome is removing.
The second is audit scope. Buyers should request, in writing, the audit periods, the controls covered and whether key ceremonies were in scope. The public accounts so far do not state this.
The third is a migration date. Chrome's removal is expected to reach devices on 27 October, and eMudhra has committed to working with impacted subscribers to migrate customers off the root, as Chrome's post describes it. A buyer should have that date and the replacement certificate's issuing chain confirmed before the removal takes effect.
