Securify

A routine key-generation ceremony at Indian certificate authority eMudhra has snowballed into one of the most consequential trust infrastructure failures in recent memory. After a researcher proved he could reconstruct eight of the company’s private CA keys from publicly available certificates, every major browser vendor — Google, Mozilla, Apple, and Microsoft — moved to revoke trust, Oracle and Python shipped emergency patches, and eMudhra announced it would exit part of its certificate business entirely. The fallout is still unfolding.

What Went Wrong

On April 30, 2025, eMudhra conducted a key-generation ceremony for a set of intermediate certificate authority keys under its emSign ECC Root CA – G3 hierarchy. During that process, something went catastrophically wrong: alongside the intended strong keys, the ceremony produced a second set with absurdly small private-key values — literally numbers like 4, 56, 66, 115, 155, 156, 230, and 237. Staff then mistakenly used these weak keys when preparing the certificates. The exact root cause is still under investigation, but eMudhra has acknowledged the error.

The weak keys sat undetected for roughly 18 months, surviving two independent audits of eMudhra’s infrastructure. That changed on October 17, when independent security researcher Wayne demonstrated that he could reconstruct all eight private keys from nothing more than the public certificates themselves. He proved control of each key by signing a test message, then reported his findings to browser security teams. Mozilla independently recovered the same keys within hours of receiving the report.

The Scope of the Damage

Eight intermediate certificate authorities were compromised: six used for TLS (the protocol that secures website connections) and two used for code signing (which verifies who published a piece of software). Anyone who recovered these keys — and the researcher showed the math was trivial — could have forged trusted HTTPS certificates to impersonate legitimate websites, intercept encrypted communications, or sign malware so it appeared to come from a trusted publisher.

eMudhra maintains that none of the eight affected intermediates actually issued certificates to end users or websites, a claim supported by the absence of those certificates from Google’s Certificate Transparency logs. The company also says its root CA keys and other intermediate authorities were not affected, and that its Indian digital signature certificate (DSC) and eSign operations run on entirely separate infrastructure.

Still, the potential blast radius is enormous. Google’s records identify roughly 30,800 certificates chained to eMudhra infrastructure that may need replacement. eMudhra has issued more than 60 million digital certificates over its lifetime, and while the weak keys appear confined to eight intermediates, the trust implications ripple outward to every system that relied on the compromised root.

Industry Response: A Coordinated Revocation

The response from the browser and platform ecosystem was swift and decisive:

• Mozilla blocked the affected certificates in Firefox within hours of the initial report and pushed updates to users.
• Google deployed CRLSet updates for Chrome and Edge, blocking the compromised TLS certificates. On October 27, the removal of the emSign ECC Root CA – G3 from the Chrome Root Store began reaching supported devices. Google is now reviewing whether eMudhra’s remaining CAs should stay trusted at all.
• Apple and Microsoft both moved to distrust the affected certificates. Microsoft went further, updating the Windows Disallowed Certificate Trust List on October 20 and releasing an out-of-band Windows update on October 26 that removed seven certificates from the OS-level trust store. A separate Edge trust list update followed on October 27.
• Oracle issued an emergency Java security alert for CVE-2026-91403 (CVSS 9.1), which affects the JSSE component across Java SE 8, 11, 17, 21, 25, and 27, as well as GraalVM. The vulnerability is not a flaw in Java itself but rather the presence of the compromised eMudhra certificates in Java’s default trust store.
• Python’s security team warned developers to update pip to version 26.2.2 or later and rebuild containers that may bundle the affected certificate chain through certifi.
• India’s CERT-In issued an advisory confirming the compromise of eMudhra intermediate certificates, with particular concern about the code-signing keys.

Cloudflare also updated its services, though it reported finding no evidence of active exploitation on its own systems.

eMudhra’s Response and Business Impact

eMudhra withdrew the eight affected certificates and announced it would exit its global TLS certificate business — a segment the company says accounts for roughly 1% of its revenue. The majority-owned family business maintains that its core infrastructure was not compromised and no customer data was breached. India’s Ministry of Electronics and IT (MeitY) has formed a special investigation team, though it says the impact on Indian websites and apps was “very limited and brief.”

The market did not share that optimism. eMudhra shares hit their 20% lower circuit on the BSE, closing at ₹431.55 following the disclosure.

Why It Matters Beyond eMudhra

The incident is a stark reminder of how fragile the web’s trust model remains. The entire TLS ecosystem depends on certificate authorities generating keys correctly, storing them securely, and submitting to rigorous audits. Here, the keys were not stolen by a sophisticated attacker — they were generated wrong, with values so small a determined hobbyist could factor them by hand. And two professional audits failed to catch it.

That failure mode is especially unsettling because it is not exotic. Unlike a nation-state supply-chain compromise or a novel cryptographic attack, this was a process failure — a wrong set of keys picked up during a ceremony, then rubber-stamped through compliance checks. It raises hard questions about whether the CA audit ecosystem is testing the right things.

What You Should Do Now

If you are a system administrator, developer, or security professional, here is a practical checklist. First, ensure Windows certificate trust updates and browser component updates are reaching all managed devices — do not restore the removed trust locally without a thorough risk assessment. Second, if you run Java applications, apply Oracle’s emergency patch for CVE-2026-91403 across all affected versions. Third, Python developers should update pip to 26.2.2 or later, update the certifi package, and rebuild any containers that may bundle the old certificate chain. Fourth, review any certificates in your infrastructure that chain to eMudhra roots and begin the replacement process. Fifth, if you operate disconnected Azure virtual machines or VM Scale Sets, check for updated images in the Azure Marketplace. Finally, monitor Microsoft’s Trusted Root Program announcements — the company is still evaluating eMudhra’s remaining root certificates, and further revocations are possible.

The eMudhra incident will likely accelerate existing conversations about certificate transparency enforcement, shorter certificate lifetimes, and automated issuance. For now, the immediate priority is ensuring that no system under your control still trusts the compromised keys.