The eMudhra key that was the number 4

On 17 October 2026, a researcher found that eight intermediate certificate authority keys created by eMudhra could be guessed in seconds: each private key was a whole number below 256.

One of them was the number 4 (The Register ↗). Chrome blocked the affected web certificates within two hours of the report, and within days Mozilla, Google, Apple and Microsoft had all moved to distrust eMudhra’s emSign ECC Root CA - G3. The keys were created on 30 April 2025, about 17 months earlier. eMudhra says the hierarchy passed two independent audit cycles in that time, and on 22 October it said it would leave the global SSL/TLS certificate business (eMudhra ↗).

What was wrong with the keys

A certificate authority signs certificates with a private key that has to be a very large random number. Mozilla’s incident report says the eight affected keys were all zeros except for their last byte, so anyone could recover them by trying the first 256 values (Mozilla ↗). They came from a batch of P-384 intermediates generated on 30 April 2025. Six issued website (TLS) certificates and two were for code signing, and Sectigo had cross-signed all eight.

The 8 impacted keys all used integers less than 256.Dennis Jackson, Mozilla, in its incident report

eMudhra’s explanation is that an approved change to its key-generation ceremony tested a wrap and unwrap step, a flaw in the ceremony script created a second, weak set of keys on the hardware security module, and that set was used by mistake because its labels looked like those of the real keys. It says the exact root cause is still to be confirmed and that it has commissioned an independent expert review (eMudhra ↗).

How it was found

The finder, named in Mozilla’s records only as Wayne, ran Google’s open-source paranoid_crypto ↗ tool with its default settings over the certificates in CCADB, the public database the browser root programs share. He found the weak keys at 16:27 UTC on 17 October and reported them to Apple, Chrome, Microsoft, Mozilla and eMudhra at 18:05 UTC (Mozilla dev-security-policy ↗).

The keys had been readable in public certificate data the whole time, and the check that surfaced them is open source.

Who did what

Who was affected

Google says no certificate chaining to the six web intermediates was logged in Certificate Transparency before its block, and Chrome requires that logging, so no forged certificate from them could have been trusted by default in Chrome (Google ↗). eMudhra says seven of the eight keys were never used in production, the eighth issued no certificates, its infrastructure was not breached, and its Indian digital signature and eSign services run on separate infrastructure and are unaffected (eMudhra filing ↗). MeitY described the impact on Indian websites and apps as very limited and brief (MeitY ↗).

The wider effect comes from the root removal. On 21 October about 30,800 unexpired certificates chained to emSign ECC Root CA - G3, 99.9% of them through two Internet2/InCommon intermediates, by Chrome’s count in the incident report (Mozilla Bugzilla ↗). eMudhra says those customers are moving to its G1 RSA root (eMudhra ↗).

What to check now

• →Search Certificate Transparency logs (crt.sh, for example) for your domains, and replace any certificate that chains to emSign ECC Root CA - G3 or to the G3B and G3C intermediates.
• →Update trust stores on servers, containers and build images, which follow their own update cycles. Apple notes that command-line tools on macOS that read /etc/ssl/cert.pem, such as curl and git, keep accepting the certificates until a future macOS update (Apple ↗).
• →Check code-signing trust on Windows: Microsoft’s Disallowed list blocks all eight keys, including the two code-signing intermediates (Microsoft ↗).
• →If you operate in India, follow CERT-In advisory CIAD-2026-0050: update trust stores, replace affected certificates and watch Certificate Transparency logs (CERT-In ↗).

What the audits covered

eMudhra’s hierarchy is audited under the WebTrust scheme by BDO International, and the audit period on record runs from 1 June 2025 to 31 May 2026 (CCADB). eMudhra says the hierarchy passed two independent audit cycles while the weak keys were in place.

The CA/Browser Forum’s Baseline Requirements set the rules for key generation. Root keys, and subordinate keys operated by another party, must be made with a written script in a ceremony that a qualified auditor witnesses or films; for a CA’s own subordinate keys this is a recommendation (Baseline Requirements, section 6.1.1.1 ↗). Mozilla’s records also show that in June 2025 the revocation lists for the six web intermediates were published with invalid signatures, which eMudhra fixed by re-signing them with the same keys (Mozilla Bugzilla ↗).

The pattern

So what: the weakness sat in public data for about 17 months, through a full audit period, until an open-source tool run against that data surfaced it.

Pattern: an audit establishes that a process is sound; a rule checked against the real artefacts every time they change shows that its output still is. Most security programmes need both.

The same idea sits behind the plain-English rules MATT re-proves for software products on every release, and behind the 70% of CISOs in a16z’s new survey who want every fix retested (what 100 CISOs told a16z).