eMudhra's Eight-Bit CA Keys: What Happened, and What the Company's Statement Leaves Out

On 17 October 2026, a researcher emailed Apple, Google, Microsoft, Mozilla and eMudhra with a short message: the private keys behind eight of eMudhra's intermediate certificate authorities could be recovered from their public certificates. Within hours, Chrome and Firefox had blocked them. Within four days, Mozilla and Chrome had moved to remove trust in the root they chained to, CERT-In had issued an advisory, India's IT ministry had set up a special team to investigate, and eMudhra's share price had fallen 20%.

eMudhra is one of India's largest certifying authorities, and a listed company. Its response to the incident has drawn sharp criticism from the security community, and having read it against Mozilla's public incident record, I think the criticism is fair. This post covers what happened, why it matters, and where the company's account does not match the evidence.

At a glance

• What: Private keys for eight eMudhra intermediate CAs (six for TLS, two for code signing) were trivially recoverable
• How weak: The P-384 private keys were numbers smaller than 256. A properly generated key is a random 384-bit number.
• How long: Generated on 30 April 2025; reported on 17 October 2026. About 18 months.
• Reported by: An independent researcher, Wayne, on 17 October. Mozilla's Dennis Jackson opened the public incident bug.
• Response: Chrome and Firefox blocked the intermediates on 17 October, Apple and Microsoft followed, eMudhra revoked all eight on 18 October, Sectigo revoked its cross-signatures, and Mozilla and Chrome are removing the emSign ECC Root CA - G3
• Misuse: No certificates from the affected TLS intermediates were found in Certificate Transparency logs before they were blocked. No confirmed exploitation as of 22 October.
• Not affected: eMudhra's Indian DSC and eSign services, which run under a separate CCA-regulated hierarchy, according to CERT-In and MeitY

What actually happened

A certificate authority's whole job rests on one secret: its private key. With it, you can sign a certificate for any website and every browser that trusts the CA will accept it. That is why CA keys are generated in formal "key ceremonies" on hardware security modules (HSMs), with scripts, witnesses and auditors.

On 30 April 2025, eMudhra ran a ceremony that generated 24 intermediate CAs. According to its own account in the Mozilla bug, an approved deviation from the normal script was added to test a key wrap and unwrap step. A flaw in that code created a second, weak key pair on the HSM next to each intended strong one. The keys had similar labels, so staff used the weak ones to create the certificate requests. Those were signed by eMudhra's roots and sent to Sectigo, which cross-signed them too.

How weak? An elliptic-curve private key is just a number. For P-384, it should be a random number around 384 bits long. These were single bytes. Scott Helme lists values like 4, 56 and 115. Recovering one means trying at most 255 numbers, or, as Mozilla's Dennis Jackson described it, running a textbook discrete-log algorithm that finishes almost instantly. After the report came in, Mozilla independently recovered the keys in under two hours.

From key ceremony to root removal

Once reported, the ecosystem moved fast. Chrome pushed a CRLSet block the same evening and Firefox blocked the six TLS intermediates through OneCRL by 22:59 UTC. eMudhra revoked all eight the next morning. Sectigo revoked its eight cross-certificates. Apple and Microsoft blocked them. Go shipped new releases, Node.js updated its bundled CA store, and Linux distributions updated their certificate packages. Because many clients do not check revocation reliably, Mozilla and Chrome decided to remove trust in the parent root entirely. Chrome expects that change in its stable release on 27 October.

Why it matters even though nothing was found misused

Nobody has shown that these keys were abused. Google says no certificates chaining to the six TLS intermediates appeared in Certificate Transparency logs before they were blocked. That is genuinely good news.

But "nothing found" is not the same as "nothing happened":

• Browsers enforce CT; most other software does not. Go, Python, Node, Java and curl generally do not check whether a certificate was logged. A forged certificate kept out of CT logs would have worked against them for 18 months, and would leave no public trace.
• The keys are now effectively public. Mozilla notes several people recovered them independently, and some published the results. CT search provider ctlogs.dev reports more than 100,000 certificates logged from the affected TLS CAs since 19 October, almost all with joke names like "we-are-lost.com", issued after the CAs were revoked. That is what it looks like when anyone can sign as a CA.
• Two of the keys were for code signing. Software signed with them could look like it came from a trusted publisher.
• Revocation does not reach everything. VPN clients, container images built before 20 October, embedded devices and forgotten servers with their own trust stores keep trusting what they trusted, until someone updates them.

Where eMudhra's statement doesn't hold up

eMudhra published a statement explaining how it happened. It was widely shared and widely criticised. Here are its main claims next to the public record.

eMudhra's claims next to the public record

"The keys were generated on FIPS 140-2 Level 3 certified Hardware Security Modules"

This is true and beside the point. By eMudhra's own account, the weak keys were also generated on the HSM, by a script it ran. FIPS certification says the hardware module does what it should when it is asked. It says nothing about what a ceremony script asks it to do. The failure eMudhra describes is a process that generated the wrong keys and then used them, with no check on the most basic property of a private key: whether it is a big random number.

"The issue went undetected for about 18 months, through two independent audit cycles"

This is written as if it were mitigating. It is the opposite. If two audits passed a CA whose keys fit in one byte, that is a finding about the audits.

It also isn't quite true that it went undetected. In May 2025, CT monitors noticed that CRLs from these same intermediates had invalid signatures (Mozilla Bug 1970728). eMudhra fixed that by re-signing the CRLs with the second, weak keys. The signatures then validated, and the symptom of having two key pairs went away. Chrome is now asking eMudhra directly when staff first noticed the duplicate keys, why they re-signed rather than stopping to investigate, and why the 2025 incident report did not mention the duplicate keys or the ceremony deviation.

"Reverse-engineer the weak keys, reportedly with the help of AI-assisted tooling"

This makes the discovery sound sophisticated. It wasn't. When a private key is a number below 256, you recover it by counting. Mozilla's own engineers did it within two hours of the report, and others did it independently. The interesting question is not how the researcher found it. It is why nobody at eMudhra, in two audits, or in the ceremony itself checked.

"Confined to one customer ecosystem" and "very limited"

eMudhra says only one of the eight intermediates went into production, and that the impact was confined to one customer ecosystem in the United States. MeitY says the impact on Indian websites was "very limited and for a very short interval," and accused some social media accounts of fear mongering.

That framing measures the wrong thing. The risk was never only the certificates eMudhra issued. It was that anyone who checked could have issued certificates for any domain, and the problem existed for 18 months. Mozilla's bug also records that removing the root means about 30,000 legitimate certificates have to be migrated to another hierarchy. "Our systems were not breached and no data was lost," eMudhra's other reassurance, is also true and irrelevant: nobody needed to breach anything to get a key that small.

What eMudhra did right

To be fair: it acknowledged the report the same evening, revoked all eight intermediates within a day, stopped issuance from the affected root, and says it is re-verifying every key ceremony it has run. Those are the right moves. The criticism is about the explanation, not the incident response.

The India angle

The Indian side of eMudhra is a different business. Its Digital Signature Certificates and eSign services, used for tax returns, company filings and signing documents, are regulated by the Controller of Certifying Authorities under MeitY. CERT-In and MeitY both say those were not affected, and eMudhra says they run on separate HSM infrastructure in India. Nothing public contradicts that, but it rests on the company's description of its own setup, and MeitY's special team should be expected to confirm it.

It still matters for India. eMudhra is an Indian success story in a field where the country has few global players, and browsers and operating systems decide which CAs the world trusts. CA distrust decisions are usually about whether the operator can be trusted to tell the truth about its mistakes, not about the mistake alone. Chrome's twelve open questions in the bug are that test. How eMudhra answers them will shape how the world looks at Indian trust infrastructure, more than the bug itself.

What to do

• Update browsers and operating systems. Chrome, Firefox and Safari block the affected CAs, and Microsoft has pushed its own block. Check older Windows machines, where reports say Edge lagged.
• Update every other trust store: Go (1.27.3 or 1.26.10), Node.js (22.23.4, 24.22.1 or 26.12.1), Python's certifi, and your Linux distribution's ca-certificates package.
• Rebuild container images. An image built before 20 October carries the old trust store, whatever the host has.
• Ask VPN, appliance and embedded vendors whether their products trust the affected CAs, and when an update ships.
• If you hold certificates from the emSign ECC Root CA - G3 hierarchy, replace them before Chrome's root removal reaches stable on 27 October.
• Never "fix" a certificate error by disabling verification. CERT-In calls this out specifically, and it is the most likely way this incident hurts someone now.

The takeaway

A key that fits in one byte is not a sophisticated failure. It is a missing sanity check, in a ceremony designed to have many of them, followed by an anomaly in May 2025 that was patched over instead of investigated. Browsers did their part in hours. What's left is for eMudhra to give straight answers, and for the audit regime that passed this twice to explain how.

This article reflects public information as of 22 October 2026, 09:30 IST. It will be updated as eMudhra answers the open questions in the Mozilla incident bug and as MeitY's investigation reports.

Sources

• Mozilla Bugzilla 2083449: eMudhra, private key compromise of intermediate certificates
• CERT-In advisory CIAD-2026-0050: Compromise of eMudhra intermediate CA certificates
• eMudhra: Statement on recent certificate security incident
• Scott Helme: Eight bits of trust, eMudhra's CA keys cracked in milliseconds
• BleepingComputer: Mozilla, Google, Apple block compromised eMudhra CA certificates
• SecurityWeek: Browsers block eMudhra intermediate CAs over recoverable private keys
• ctlogs.dev: eMudhra intermediate CA compromise (October 2026)
• lorbic: The eMudhra CA compromise
• ThePrint: MeitY sets up team to probe eMudhra certificate breach
• Business Today: MeitY says Indian DSC and eSign unaffected
• The South First: Explained, the eMudhra digital certificate fiasco
• Aviatrix: eMudhra TLS compromise, eight weak keys and the attack window
• Node.js: October 21, 2026 security releases (includes the eMudhra CA update)