Eight keys anyone could compute: what the eMudhra CA compromise means for you

Most certificate scares start with a stolen key. This one didn't need a thief. On 17 October a security researcher told the browser makers that eight intermediate certificates belonging to eMudhra, an Indian certificate authority, had private keys that anyone could work out from the public certificates themselves. Security researcher Scott Helme says he recovered all eight in under a second [1].

An intermediate CA is the part of the system that signs the certificates websites show your browser. Whoever holds one of these keys can issue certificates that browsers accept, for any domain. Six of the eight were TLS intermediates chaining to the emSign ECC Root CA - G3, which sat in the Chrome, Apple and Mozilla root stores. The other two were for code signing [1].

The good news is how fast the big players moved. The less comfortable news is where the fix didn't reach automatically.

What happened, hour by hour

Chrome received the report at 18:05 UTC and had blocked the six TLS intermediates by 19:45. Firefox finished its own block a few hours later. Apple followed on 19 October, Microsoft and the Go project on 20 October, and Mozilla removed the emSign ECC Root CA - G3 from its trust store the same day [1][2]. In India, CERT-In issued advisory CIAD-2026-0050 on 21 October, and Node.js shipped releases with an updated CA bundle on the same day [1][3].

Chrome found no certificates chaining to the six TLS intermediates in public Certificate Transparency logs before its block, and eMudhra says only one of the eight was in production and none had issued certificates to customers [1]. CERT-In said that, as of 21 October, there was no confirmed malicious use [1]. That is reassuring, but it is also the limit of what anyone can prove: there is no reliable way to detect past misuse of a key that never left the building.

Why it happened

The keys were generated with too little randomness. According to eMudhra, a flaw in its 30 April 2025 key ceremony, run on FIPS 140-2 Level 3 hardware security modules, produced a second set of weak keys alongside the intended ones; the key wrap and unwrap step was involved, and the root cause is still under investigation [1][4]. In other words, the certified hardware worked as designed and the process around it did not. Those weak keys then sat inside trusted certificates for about eighteen months.

What it means in India

Officials told ThePrint that eMudhra's digital signature certificate (DSC) and eSign services, which are regulated by the Controller of Certifying Authorities, run on separate infrastructure and are unaffected. MeitY set up a team to investigate. The impact on Indian websites was described as "very limited and for a very short period." eMudhra says its global TLS business is about 1% of revenue, but its shares fell about 20% on 21 October [1].

For most Indian companies the risk is not that someone forged a certificate last week. It is that a forged or revoked certificate would still be trusted somewhere inside their own systems today.

The part most teams miss

Browsers updated themselves. Much of the software that talks to your APIs, payment partners and internal services did not. A Go service, a Node.js worker, a Python job using certifi, a Rust binary with webpki-roots or a PHP app using Composer's CA bundle each carries its own list of trusted certificates, frozen at the moment it was built [1][3][5]. So does every container image built from an older base, and plenty of appliances.

The fix is ordinary but easy to skip: update the trust store, then rebuild and redeploy whatever bundled the old one. Red Hat's packages were still pending when the advisories went out, and its interim workaround blocks whole roots, which can break legitimate certificates unless you restore them by hand [1].

A checklist for your own setup

• Do we know which of our services, images and appliances carry their own CA bundle?

• Have we updated ca-certificates on every host, and rebuilt images that copy the bundle in at build time?

• Are our Go, Node.js, Python, Rust and PHP services on releases that reject the eight eMudhra keys?

• Do any of our certificates, or our vendors' certificates, chain to the emSign ECC Root CA - G3? If so, have they been reissued from another hierarchy?

• Do our HTTP clients check revocation, or will they keep trusting a blocked certificate until the code changes?

• Could we answer "where do we trust certificate X?" within an hour the next time this happens?

Get your complete exposure report

Incidents like this one are rarely about the headline system. They are about the forgotten service that still trusts what everyone else has blocked. NexusVoid maps what you expose to the internet and the components behind it, including outdated runtimes, stale CA bundles and certificates that chain to revoked roots, and gives you a fix for each finding. Our 24/7 monitoring then tests every newly disclosed issue against your stack as it appears. Get your complete exposure report →

References

1. The Hacker News. "Eight eMudhra CA Keys Compromised, Triggering Emergency Fixes Across Browsers and Software." October 2026. thehackernews.com

2. Mozilla Security Blog. "Protecting Firefox users following the compromise of eMudhra intermediate certificates." 20 Oct 2026. blog.mozilla.org

3. Node.js. "Wednesday, October 21, 2026 Security Releases." nodejs.org

4. Help Net Security. "eMudhra security blunder left trusted CA signing keys exposed to anyone." 21 Oct 2026. helpnetsecurity.com

5. Endor Labs. "eMudhra CA Compromise: The Trust Stores You Didn't Patch." endorlabs.com