eMudhra CA Key Compromise: What Happened and What It Means

Eight intermediate certificate authority certificates belonging to the Indian trust-services company eMudhra were found to be signed with private keys so weak they could be recovered in minutes — not stolen in a hack, but reconstructed mathematically because the keys themselves were almost not random at all. Mozilla, Google, Apple and Microsoft moved within hours to block the affected certificates, eMudhra revoked them, and the incident has since snowballed into the biggest public-trust failure a commercial certificate authority has had in years, triggering a government investigation in India and a 20% one-day drop in eMudhra's stock price.

What actually happened

eMudhra is a certificate authority (CA): a company whose job is to vouch, cryptographically, that a website or piece of software is who it claims to be. Browsers like Chrome, Firefox, Safari and Edge trust a short list of root CAs, which in turn delegate day-to-day certificate issuing to "intermediate" CAs. If an intermediate CA's private key leaks, anyone holding it can mint a certificate for any domain they like — including, in theory, your bank's website — and browsers would accept it as genuine.

That is exactly the scenario that was reported to Mozilla's certificate authority program on October 17, 2026. A researcher using the handle Wayne contacted Mozilla, with the report forwarded by Google's Chrome Root Program, stating that the private keys of eight eMudhra intermediate certificates had been compromised. Crucially, Wayne didn't just claim this — he proved it, by using each of the eight private keys to sign a short message, something only someone who actually holds the key can do.

Timeline: 18 hours from report to revocation

Mozilla's own incident bug (filed as Bugzilla bug 2083449) lays out an unusually fast-moving sequence once the report landed:

eMudhra's own published timeline confirms the same broad strokes, with the company noting it revoked the affected intermediates "within 14 hours of confirming the issue" on its incident-update page. A parallel writeup also circulated on the oss-security mailing list once Mozilla's bug was unsealed on October 20.

How weak were the keys, exactly?

This wasn't a borderline cryptographic weakness — it was close to no protection at all. The affected certificates used the P-384 elliptic-curve algorithm, part of the CA/Browser Forum's baseline requirements for publicly trusted TLS certificates, which should produce a private key that is, for all practical purposes, an unguessable 384-bit random number. According to Mozilla's analysis in the incident bug, the actual private "scalars" used for all eight compromised keys were integers smaller than 256 — meaning the key was effectively zero in every bit except the last byte.

A key that small can be found by brute-force in a fraction of a second, or via a textbook "baby-step giant-step" discrete-log search (a standard technique described on certificate authority and public-key cryptography references) across the 256 possibilities. eMudhra traced the cause to its own key-generation tooling: a script used during an April 30, 2025 key-generation ceremony had a defect that produced two sets of keys for each certificate — a properly generated set, and a second, much weaker set — and the weaker set was mistakenly the one wired into the live certificates, reportedly because of similarly named key labels.

eMudhra said the keys were generated inside hardware security modules (HSMs), telling Mozilla: "Keys were generated in hardware and the hardware in use was Utimaco HSMs," and that "a flaw in the code resulted in the second pair of keys being created onboard which were weaker." In a later comment on the same bug, the company added: "We have accepted our error without qualification."

Which certificates were affected

The eight compromised certificates were part of a batch of 24 intermediates created in that April 2025 ceremony, spread across three "series" (A, B and C) using both RSA-4096 and P-384 keys for domain-validated (DV), organization-validated (OV), extended-validation (EV) and code-signing (CS) purposes. Series A had already been revoked and replaced in May 2025 for an unrelated reason, and Mozilla was not able to recover those keys — only the P-384 keys from the B and C series were weak:

Several of the TLS intermediates had also been cross-signed by Sectigo, which has since revoked its own cross-signatures as a precaution. A separate, related bug Mozilla had already been tracking (bug 1970728) found that the six TLS intermediates' revocation lists (CRLs) had been failing cryptographic verification since as far back as May 23, 2025 — meaning the normal safety net for checking whether a certificate had been revoked had itself been broken for roughly 17 months before anyone caught it.

How the browsers and root programs responded

Because intermediate CA compromises threaten the trust model the entire web relies on, the response from browser vendors was immediate rather than waiting for a lengthy investigation. Firefox blocked the certificates the same night via its OneCRL revocation-distribution system; Chrome's Root Program, which had forwarded the original report, acted alongside it; Apple and Microsoft followed over the next two days. Google has gone a step further and is removing eMudhra's emSign ECC Root CA-G3 from the Chrome Root Store outright, with that change reaching devices on October 27, 2026 — a step the browser normally reserves for roots it no longer trusts at all, not just specific intermediates under it.

eMudhra itself disputes the framing used by some early coverage that this was a "root" compromise, noting on its incident page that the removal of two of its root CAs from Mozilla's trust store was "voluntary and planned" business consolidation and separate from the intermediate key issue — though the emSign ECC Root CA-G3 removal that followed days later is a direct consequence of this incident.

Was any fraudulent certificate actually issued — and is your data at risk?

This is the question that matters most for ordinary users, and the honest answer is: not confirmed, but the exposure window was long. eMudhra has said it is "not aware of any evidence that the weak keys were recovered or exploited" before the researcher's October 17 report, and that none of the eight intermediates had publicly trusted end-entity TLS certificates traceable to them in the Certificate Transparency logs that all public certificates must be logged to. That is reassuring, but it is also not proof of safety: the keys were generated 18 months before anyone noticed they were weak, during which time they sat inside browsers' trust stores as fully valid, trusted intermediates.

For most people browsing the web, there is nothing to install or change — browser and OS updates distributed by Mozilla, Google, Apple and Microsoft handle the blocking automatically. The practical risk falls mainly on organizations that had certificates issued from eMudhra's affected G3 hierarchy (eMudhra says this affects what it calls "one customer ecosystem" it is actively migrating) and on any software that maintains its own separate certificate trust store rather than relying on the OS or browser — those systems may keep trusting the weak certificates until they are patched or updated independently.

The fallout for eMudhra

The business consequences have been immediate. eMudhra's publicly traded shares on India's exchanges fell 20% — hitting the daily lower circuit limit — the day after the company's most detailed disclosure on October 21. India's Ministry of Electronics and Information Technology (MeitY) has set up a dedicated team to investigate, while stating publicly that the incident is confined to eMudhra's international "Global TLS" certificate business and does not touch its domestic Digital Signature Certificate (DSC) or eSign services. Credit rating agency ICRA, in a note affirming eMudhra's existing ratings on October 23, flagged that the company is exiting the global public TLS certificate-issuance business as a result. eMudhra's own updates maintain that its root CA private keys, its signing products (emSigner, CertiNext, emCA, Privatrust, SecurePass) and the large majority of its TLS certificate base — which chains through other, unaffected hierarchies — were never implicated.

It's the latest reminder that certificate authorities, despite sitting at the foundation of HTTPS trust, are run by companies that can make basic engineering mistakes — a theme that has also played out this month in other critical vulnerability disclosures requiring emergency patching across widely used infrastructure software, and in this month's cloud-platform security incident at Railway.

What to do next

If you're an everyday user: do nothing beyond keeping your browser and operating system up to date, which is always good practice and is how this kind of certificate revocation reaches you automatically.

If you run a website, service, or internal system that uses an eMudhra-issued TLS or code-signing certificate from the emSign G3 hierarchy, check eMudhra's own incident page for migration instructions — the company says it is moving affected and at-risk customers to replacement certificates, including Sectigo-issued alternatives, at no additional cost, and that the majority of reissuance (eMudhra has cited a figure around 97%) is happening automatically through ACME-based automated certificate renewal.

If you maintain software with its own hardcoded certificate trust store — embedded devices, custom TLS stacks, older enterprise tools — this is a good prompt to check whether that trust store still includes the now-distrusted emSign intermediates or the emSign ECC Root CA-G3, independent of your browser or OS vendor's own updates.

Frequently asked questions

See the FAQ section below for quick answers on what eMudhra is, whether personal data was exposed, and what a CA key compromise means in plain terms.

Written bySana Qureshi

Sana Qureshi runs the security and privacy desk. She reports on actively exploited vulnerabilities, vendor patches and data breaches, and covers the password managers, VPNs and authentication tools readers use to protect themselves. Her alerts cite vendor advisories, CISA and the CVE record directly.

More from Sana QureshiAll Security & Privacy coverage