eMudhra's Eight Revoked CA Keys Were Guessable From 256 Values. The Root Distrust Next to Them Is the Bigger Job

eMudhra, an Indian certificate authority, says a flaw in one step of an April 2025 key ceremony produced eight intermediate CA keys that anyone could rebuild by trying 256 numbers. Dennis Jackson of Mozilla put it plainly in the public bug report: "The 8 impacted keys all used integers less than 256." They sat in browser trust lists for about 18 months and passed two audit cycles. As of October 22, eMudhra says it knows of no evidence anyone used them.

A test step that kept its output

eMudhra says it has not yet confirmed the exact root cause, but its account so far fits in one sentence. "The problem was a flaw in one step of the ceremony procedure," its incident page says. A key wrap and unwrap step produced a second, weak set of keys next to the strong ones. The weak set was the one published to the browser root stores.

In the Mozilla thread, eMudhra added that an approved deviation for a wrap and unwrap test led to the second pair, and that the key labels were similar enough that the wrong pair went into the signing requests. Those requests went to Sectigo for cross-signing. eMudhra also says the keys were made on hardware security modules certified to FIPS 140-2 Level 3, and calls suggestions otherwise incorrect. A commenter in the same thread asked how certified hardware produced keys this small. As of this writing, that question has no answer.

From report to block in under five hours

A researcher who goes by Wayne spotted broken elliptic curve keys while checking public CCADB data on October 17. Around 18:05 UTC, Wayne emailed Apple, Chrome, Microsoft, Mozilla and eMudhra with signed attestations. eMudhra acknowledged the issue at 21:28. Mozilla recovered the private keys on its own at 21:48. By 22:46, Chrome's CRLSet listed six TLS keys as revoked, and Mozilla finished its OneCRL block at 22:59.

eMudhra revoked all eight intermediates the next morning. Six could issue TLS certificates. Two were for code signing, which Microsoft trusts. For Firefox and Chrome, the blocklist updates arrived without a browser restart, according to Bleeping Computer.

Two different blast radii

The eMudhra statement leans on one fact. Seven of the eight intermediates were never used in production, and the one that was had issued no certificate. "No certificates had been issued from any of them," it says. Certificate Transparency records, which eMudhra cites, back that for the intermediates.

The trouble is a second number. In the Mozilla thread, eMudhra said about 30,000 certificates need migration, roughly 97 percent through automated ACME renewal. Chrome counted about 30,800 unexpired precertificates chaining to the distrusted G3 root, and 99.9 percent of those came from two InCommon subordinate CAs. eMudhra's page calls the root distrust "contained to a single customer ecosystem in the United States." Both statements can be true. They count different things: the weak keys never signed anything, but the root above them did.

The company has begun offering Sectigo-issued certificates as a replacement, and says its G1 roots remain fully supported.

Old software may not have heard

Browsers are the easy case. Bleeping Computer reports that software with its own certificate store, or software that never checks revocation, can keep trusting the dead intermediates until updated, and that macOS's built-in curl may be one of them. Mozilla also had to fix a gap where some Android Firefox profiles skipped the blocklist, shipped in Firefox 158.0.2.

India's IT ministry, MeitY, said the effect on Indian websites and applications was "very limited and for a very short interval," and that its digital signature and eSign services are unaffected. Business Today reported the ministry has formed a special team to investigate and will share more once it finishes.

What nobody has explained yet

Chrome posted twelve questions in the bug thread that remain largely unanswered. They cover why the second key pair and an earlier bug about invalid eMudhra CRL signatures, filed in 2025, were not disclosed. By eMudhra's own explanation in the thread, those CRLs were first signed with the correct keys, produced invalid signatures, and were then re-signed with the flawed ones. Other commenters want the ceremony script, the witness reports, the HSM firmware version and the name of whoever approved the deviation.

Mozilla has not yet examined eMudhra's RSA intermediates from the same April batch. No public tally of comparable weak-key cases turned up in this reporting, so this piece does not call the episode unprecedented. The keys are dead. The open item is whether a ceremony that two audits passed gets a full public write-up, which eMudhra says is coming.