eMudhra CA Key Compromise: What It Means and What to Update

October 20, 2026: Mozilla and Google's Chrome Root Program confirmed that the private keys of eight intermediate certificate authorities run by eMudhra, an Indian certificate authority, were compromised. Six of the CAs issued website (TLS) certificates and two issued code-signing certificates. Browsers, operating systems and the Go language have all moved to block them. Canonical: emudhra-intermediate-ca-keys2026. Primary source: Mozilla Security Blog.

A certificate authority's job is to vouch for who runs a website or who published a program. An intermediate CA does the day-to-day signing on behalf of a trusted root. Whoever holds an intermediate's private key can issue certificates that browsers accept for any domain, which enables convincing impersonation of banks or email providers and interception of encrypted traffic. A code-signing key does the same for software, making malware look like it came from a legitimate publisher.

What happened

• October 17, 18:05 UTC: a researcher credited as "Wayne" reported the compromised keys to the Chrome Root Program.
• 19:45 UTC: Chrome had pushed a CRLSet update blocking the six TLS intermediates.
• 20:06 UTC: Mozilla received the report. By 22:59 it had pushed a OneCRL block to Firefox installations with standard settings.
• October 19: Apple blocked the certificates, and other trust stores were notified.
• October 20: Microsoft blocked them, Mozilla and Chrome confirmed the compromise publicly, Go shipped fixes, and Mozilla removed the emSign ECC Root CA - G3 from NSS.

Mozilla engineer Dennis Jackson published the list of affected certificates. According to his site, eMudhra has revoked all eight.

Technical analysis

What was compromised

The eight intermediates are eMudhra's DV, OV and EV TLS CAs in two variants each (G3B and G3C), chaining to emSign ECC Root CA - G3, plus two code-signing CAs (EM OV CS CA - G3B and G3C). Each also exists as a copy cross-signed by Sectigo with the same public key, which is why trust stores had to block the keys themselves rather than just one certificate.

How the keys got out

This has not been disclosed. In the words of The Hacker News, it is not known how the keys left eMudhra, when, or whether anyone besides the researcher holds them. Mozilla says it is working with the CA and other root programs on the root cause. As of October 20 eMudhra had not published a statement, which is why we list the incident as confirmed by root programs rather than by the company.

Was anything misused?

So far, no evidence. No TLS certificate chaining to the six TLS intermediates had been logged to Certificate Transparency before Chrome's block, and browsers that require Certificate Transparency would not have trusted an unlogged one by default. Chrome said it found no other instances of this failure mode across its root store. There is, however, no public way to check for past misuse of the two code-signing keys or for unlogged certificates presented to software that does not enforce Certificate Transparency.

Why revocation alone was not enough

Revoking a certificate only helps if software checks revocation, and much of it does not. Browsers therefore used their own push channels instead: Chrome's CRLSet and Firefox's OneCRL deliver blocklists that work without asking eMudhra's servers anything. Software outside the browser has no such channel. A Go program, a Python script using certifi, or a firewall appliance with a built-in CA list keeps trusting whatever was in its bundle at build time. That is why Go issued security releases and why CA bundles are removing eMudhra's root entirely, so that the keys stop working even where revocation is never checked.

Verified vs unverified

• Verified (Mozilla, Chrome Root Program): the eight keys are compromised; the timeline of the blocks; no TLS certificates from the six TLS intermediates in Certificate Transparency before the block.
• Reported (Dennis Jackson's list): eMudhra has revoked all eight certificates.
• Unknown: how the keys were exposed, since when, whether anyone other than the reporting researcher has them, and whether either code-signing key was used to sign anything.

Impact

• Web users: low immediate risk on up-to-date Chrome, Firefox, Safari and Edge, which now reject the keys.
• Software that ships its own trust list: higher risk. Go programs, Python apps using certifi, Rust apps using webpki-roots, older Firefox builds that cannot receive remote updates, and appliances or embedded devices keep trusting the keys until they are updated.
• eMudhra customers: sites and signed software using certificates from these intermediates need replacement certificates from a different chain, and eMudhra's root faces removal: Chrome plans to drop emSign ECC Root CA - G3 and is reviewing emSign Root CA - G1.

What to do

1. Update browsers and operating systems, including Firefox 158.0.1 or ESR 115.43.1 / 153.5.1 where automatic blocklist updates are disabled.
2. Update Go to 1.27.3 or 1.26.10 and rebuild Go services, which embed Go's certificate verification (CVE-2026-111943).
3. Update bundled CA lists: NSS 3.131.1, Python certifi 2026.10.19, Rust webpki-roots 1.0.10 and Homebrew ca-certificates. Node.js and Composer fixes were still pending on October 20, so watch for those releases.
4. Check your own certificates. If any site or signed binary you operate chains to the eight intermediates on the published list, reissue from another CA now.
5. Treat software signed by the two code-signing CAs with caution until eMudhra explains the timeline of the exposure.

Related reading

Trust in the tools and channels that deliver software keeps being the weak point this month. The OVHcloud CLI release hijack showed how swapped files can match their published checksums (our write-up), and AOMEI's compromised update servers pushed malware through an official channel (our write-up).

Sources

Mozilla Security Blog • Chrome Root Program (dev-security-policy) • The Hacker News • Affected certificate list • Mozilla advisory MFSA 2026-111