Identity

eMudhra CA keys leaked: update Go and trust stores now

Eight eMudhra intermediate CA keys were recoverable from public certificates. Which clients are still exposed, what breaks on October 27 and how to update.

By Yaali. October 23, 2026, 7 min read, Identity, Threat intel, Patching.

The private keys of eight intermediate certificate authorities (CAs) run by the Indian CA eMudhra are public knowledge. They were generated so badly that anyone can work them out from the certificates themselves: one of the P-384 private keys is the number 4. A researcher who signs as Wayne reported this on October 17, Mozilla recovered the keys on its own the same evening, and Mozilla and the Chrome Root Program confirmed the compromise publicly on October 20. Six of the intermediates issue TLS server certificates and are trusted through the Chrome, Mozilla, Microsoft and Apple root programs. The other two issue code signing certificates trusted by Microsoft.

Chrome and Firefox users were protected within hours, through Chrome's CRLSet and Firefox's OneCRL blocklists, which update without a browser release. The exposure that remains is in software with its own CA bundle: Go and Node.js services, Python tools using certifi, Java keystores, appliances and containers. Go shipped 1.27.3 and 1.26.10 with a hard-coded block on the eight keys, and a long list of runtimes and distributions followed. A second change lands on October 27, when Chrome removes the emSign ECC Root CA - G3 and legitimate sites still chained to it start failing.

Timeline of the eMudhra key compromise, from the April 2025 key generation ceremony to the October 17 report and browser blocks, eMudhra's revocation on October 18, the Go release on October 19, Microsoft's block and public disclosure on October 20, and Chrome's root removal on October 27

What a compromised intermediate key allows

A TLS client trusts a server certificate when it can build a chain from it, through one or more intermediate CAs, up to a root in its trust store. Whoever holds an intermediate's private key can sign a certificate for any hostname, and every client that trusts the root will accept it. An attacker in the network path, through public Wi-Fi, a compromised router or a hijacked DNS response, can then impersonate any HTTPS site or API without a warning.

The code signing pair is a different problem. A binary signed through EM OV CS CA - G3B or G3C would look like legitimately signed software to Windows until Microsoft's block reached the machine.

Revocation does not fix this on its own. eMudhra revoked all eight intermediates for key compromise on October 18 and Sectigo revoked the copies it had cross-signed, but most non-browser clients never check revocation lists, or treat a failed check as a pass. Mozilla's notice to distributions says clients that do not reliably check revocation must distrust the intermediates directly.

The cross-signs widen the problem. Sectigo had signed these intermediates under its AAA Certificate Services root with the same public keys, so removing the emSign roots alone leaves a second path to a trusted root. So the fixes block the keys themselves, by the SHA-256 hash of each intermediate's SubjectPublicKeyInfo (SPKI, the encoded public key), which catches every copy.

How the keys leaked

A P-384 private key should be a random number of about 384 bits. Mozilla's Dennis Jackson found these were all integers below 256: zero except for the last byte. Scott Helme recovered the full set in under a second, with values including 4, 56 and 115; other researchers reported 66, 155, 156, 230 and 237.

The keys come from a key generation ceremony eMudhra held in April 2025, so they have been recoverable for about 18 months. In the Mozilla bug eMudhra blames a flaw in that ceremony, not a breach of its systems, and says its root keys and other intermediates are not affected.

Is anyone exploiting it?

No abuse has been confirmed. Google says no TLS certificate chaining to the six TLS intermediates was logged to Certificate Transparency (CT), the public logs browsers require certificates to appear in, before the block. eMudhra says none of the eight ever issued an end-entity certificate.

That only protects clients that enforce CT, which in practice means browsers. curl, Go, Python and most server-side libraries accept an unlogged certificate, and Mozilla's notice warns that unlogged or future certificates are still possible and that abuse is likely soon. Treat any client that still trusts these keys as exposed now.

What to do

Where the fix lives for each type of client: browsers and operating systems, Go, Node.js, Python, Rust, Linux distributions and appliances, with fixed versions and how to check each

1. Test your clients against a forged chain

Mozilla's Dennis Jackson runs test hosts on the incident site, served with certificates from a compromised intermediate. Run the request from the host and container your application runs in:

curl -sS https://dv-g3b-emudhra.we-have-a-problem.com and curl -sS https://dv-g3b-aaa-emudhra.we-have-a-problem.com

A certificate error is what you want; a page that loads means the client still trusts the keys. The second host tests the Sectigo cross-signed chain. curl only tests curl's own CA bundle, so repeat the check from inside a Go, Node.js, Python or Java process where those are what talk to the network.

2. Rebuild Go programs

Go 1.27.3 and 1.26.10 (CVE-2026-111943) make crypto/x509 drop any chain that contains one of the eight keys. Go links the standard library into each binary, so updating the toolchain on a build server protects nothing until every program is rebuilt and redeployed. go version -m ./yourbinary prints the Go version a binary was built with; anything older than those two releases needs a rebuild. Go 1.25 and older are out of support and get no fix. Go's notes do not say whether the block also applies when Go hands verification to the Windows or macOS system verifier, so keep those operating systems updated as well.

3. Update the other runtimes and stores

Node.js: 22.23.4, 24.22.1 and 26.12.1 block the keys and update the bundled roots. Restart the services afterwards.
Python: certifi 2026.10.19 and pip 26.2.2. Run python -m pip install --upgrade certifi in every virtual environment, and update lockfiles.
Rust: rustls-webpki 0.103.16 adds the key block; webpki-roots 1.0.10 removes the emSign ECC Root CA - G3.
Linux: install your distribution's updated ca-certificates (Debian 12 has 20250419~deb12u2, Debian 13 has 20250419+deb13u1), then rebuild container images without cached base layers.
Java: keystores often have their own copy of the CA list. Apply your JDK vendor's update for this incident and check any custom keystore.
Appliances, proxies, VPN gateways and load balancers that inspect or terminate TLS: ask the vendor for an update.

On Windows, machines that receive automatic root updates got Microsoft's block on October 20. Air-gapped machines and those with automatic root updates turned off did not, and need the update applied by hand. Apple has also blocked the intermediates, though reports disagree on when: the incident site now lists October 22, while an earlier report based on the same site gave October 19. Install current macOS and iOS updates either way.

4. Check your own certificates before October 27

Chrome's root removal reaches all devices that use the Chrome Root Store on October 27, and Mozilla is removing trust in the same root. Any certificate you serve that chains to emSign ECC Root CA - G3 will then fail in those browsers. openssl s_client -connect yourhost:443 -showcerts shows the chain; look for issuers starting emSign or EM. Replace those certificates now, from another hierarchy in the Chrome Root Store, as Google advises. About 30,000 legitimate certificates need to move, a figure given both in eMudhra's response in the Mozilla bug and by Security Brigade's Yash Kadakia, who warns that government and public sector sites on this hierarchy could face browser warnings if replacements are late.

Also check mutual TLS (mTLS) services that accept client certificates from public CAs. These keys can mint a client certificate for any name such a service trusts, so limit mTLS trust to a private CA or a pinned list.

The wider lesson

Browsers fixed this in hours with their own blocklists and CT checks; server software took days, and Go needs a rebuild. Put the trust stores inside binaries, Python environments, Java keystores and base images on your asset list, with a tested way to update all of them in one day.

Our cloud and Kubernetes security reviews look at the base images and runtimes that carry these stores, and safeguarding and hardening covers pinning mTLS trust to the CAs you actually use. Open the chat and Yaali, our AI agent, will pass your question to an engineer.

Sources: Mozilla bug 2083449, Google: Protecting Chrome and Android users, Mozilla notice on oss-security, eMudhra incident summary and test hosts, Go release history, Go issue 82345, The Hacker News, The Hacker News on Go, CSO Online, The Register, InfoQ, Rescana.