Leaked eMudhra CA Keys Mean Updates for Go, Python and Linux

What Leaked

The private keys of eight intermediate certificate authorities run by eMudhra have been compromised. eMudhra is an Indian CA that sells certificates under the emSign brand, and its roots sit in the trust stores of the major browsers and operating systems.

An intermediate CA is the certificate that actually signs the certificates websites present. A browser trusts a site because the site's certificate was signed by an intermediate, and the intermediate by a root the browser already trusts. Whoever holds an intermediate's private key can therefore issue a certificate for any domain that the chain will vouch for. Mozilla puts the risk plainly. Someone able to intercept a connection could use such a certificate to impersonate a site, then read or modify the traffic.

Six of the eight keys belong to TLS intermediates and two to code-signing intermediates.

The six TLS intermediates were issued by emSign Root TLS CA - G3 and chain up to emSign ECC Root CA - G3. Each of the eight also exists as a second certificate carrying the same key, cross-signed by Sectigo.

The person who reported the compromise proved it by signing a message with each of the eight keys, and the disclosure site publishes those signatures with the commands to verify them. How the keys left eMudhra, when, and whether anyone else holds them is not known yet.

A Timeline Measured in Hours

CRLSets and OneCRL are revocation lists that Chrome and Firefox download by themselves, so neither browser needed an update or a restart. The Firefox releases on October 20, 158.0.1 with ESR 115.43.1 and ESR 153.5.1, exist for the minority of installations whose settings stopped the list from arriving.

Why Browser Users Were Safe Early

Chrome's block works on the public key instead of the certificate. That matters because of the Sectigo cross-signs, since a block on the eMudhra certificates alone would have left the copies with the same key trusted. The Chrome Root Program said its update protected users against both.

Certificate Transparency helped too. Chrome only trusts a publicly issued TLS certificate by default if it appears in the public CT logs, and the Chrome Root Program said no TLS certificate chaining to the six intermediates had been logged before its block. So no certificate made with the stolen keys could have been trusted by default in Chrome or in any other browser that enforces CT.

The two code-signing intermediates needed no block in Chrome at all. Chrome's verifier will not build a TLS path through an intermediate restricted to code signing.

Both root programs also looked beyond eMudhra. Chrome said it evaluated every other CA certificate in its trust boundary and found no other instances of this failure mode. Mozilla said it does not believe, at this time, that other CAs are affected.

The Sectigo Cross-Signs

The cross-signed copies chain to Sectigo's AAA Certificate Services root. Sectigo's own notice says Mozilla and Chrome began dropping TLS trust in that root from April 15, 2025, which limits what the copies can do in current browsers.

The catch is everything that does not update. Older platforms and devices that still carry AAA Certificate Services as a trusted root, and never receive a revocation list, could accept a chain through one of the copies. Homebrew's ca-certificates package goes furthest here, excluding both emSign roots and AAA Certificate Services by public key.

Why Servers Are a Different Story

Browsers fetch revocation data on their own. Almost nothing else does. A Go service, a Python script using certifi, a PHP client reading the system bundle or a Java application checking against its own keystore keeps trusting a chain until its code or its root bundle changes. A revoked intermediate stays usable against those clients for as long as nobody updates them.

Filippo Valsorda, who maintains Go's cryptography packages, described the state of Linux root stores on Go's issue as "a pile of PEM files behind a dumpster". His point was that revocation has no way to reach applications there, which is why Go put the blocked keys in its own code.

Go

Go 1.27.3 and 1.26.10, released on October 19, filter out any certificate chain that contains one of the eight intermediates (CVE-2026-111943, Go issue 82345). The Go team handled it on its URGENT track and recommends upgrading immediately.

The check is in the standard library, so it only reaches a program that is rebuilt with one of those versions. Upgrading the toolchain on a build machine changes nothing until every service is rebuilt and redeployed. Go 1.25 and older are outside Go's support window and get no fix.

To see which Go version built a binary that is already deployed, run this against it.

go version /path/to/binary

Python

certifi 2026.10.19 removes emSign ECC Root CA - G3 from its bundle, and pip 26.2.2 and uv 0.13.4 carry the same change. Every virtual environment and every container keeps the certifi it was built with, so each one needs the update separately.

python3 -m pip install --upgrade certifi
grep -c "emSign ECC Root CA - G3" "$(python3 -c 'import certifi; print(certifi.where())')"

A count of zero means the root is gone from that environment's bundle.

Linux Distributions

Ubuntu's ca-certificates package is already updated for 22.04, 24.04, 26.04 and 26.10. Arch and Gentoo have shipped theirs, NSS 3.131.1 removes the root, and the curl CA bundle dated October 20 follows it. Debian and FreeBSD were still pending on October 20.

On Ubuntu, update the package and check whether the root is still linked into the system store.

sudo apt update && sudo apt install --only-upgrade ca-certificates
ls /etc/ssl/certs | grep -i emsign

On RHEL, Fedora and their relatives the system store is managed by p11-kit, and this shows whether any emSign root is still trusted.

trust list | grep -i -A2 emsign

Node.js, Java and the Rest

Node.js ships its own copy of the Mozilla root list inside the binary, so by default, updating the operating system does not change what a Node.js process trusts. No Node.js fix existed on October 20. Node.js does have security releases due on October 21, but that announcement came earlier and separately and does not say whether this is part of it. This prints any emSign roots a given Node.js still trusts.

node -e "const {X509Certificate}=require('node:crypto'); for (const p of require('node:tls').rootCertificates) { const s=new X509Certificate(p).subject; if (/emSign/i.test(s)) console.log(s.replace(/\n/g, ', ')); }"

Java reads its own keystore. Some distributions generate it from the system store and others ship it with the JDK, so check the one your runtime actually uses.

keytool -list -cacerts -storepass changeit -v | grep -i "Owner:.*emSign"

Elsewhere, Rust's webpki-roots 1.0.10 and rustls-webpki 0.103.16 are out, as are Electron 44.9.1, 43.8.1 and 42.11.16 and Elixir's castore 1.0.22. Bun and Composer's ca-bundle were still pending.

Containers

A container image carries its CA bundle and its language runtimes frozen at build time. Updating the host does nothing for the images running on it, so every image needs a rebuild once its base and its dependencies carry the fix. Images built on Debian have to wait for Debian's package, and Go services in any image need the new toolchain in the build stage.

Check Your Own Certificates

Removing a root from a bundle also ends trust in the legitimate certificates issued under it. Mozilla warned that its change will affect the availability of some servers for non-Firefox users of its trust list until those servers move to new certificate chains. If one of your sites uses an emSign certificate, clients with the updated bundles will start refusing it, so it is better found now than from a support ticket.

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -issuer

If the issuer names an eMudhra or emSign CA, check it against the list of affected intermediates and roots on the disclosure site, then plan a replacement from another CA.

What Mozilla Advises Trust Store Operators

Anyone who maintains a trust store for others, a distribution, a language package or an internal base image, gets three levels of advice from Mozilla. Where clients reliably check revocation and refuse a connection when they cannot, nothing is needed. Where the software can block individual intermediates, block the eight listed in the published file and ship the update immediately. Everywhere else, consider removing trust in the roots that signed them.

What Happens Next

Mozilla has removed emSign ECC Root CA - G3 from NSS. Chrome will remove the eMudhra root in version 43 of the Chrome Root Store. Mozilla says it will share more information as soon as circumstances allow, and the root cause has not been published.

Certificate Transparency shows only certificates someone chose to log, so it cannot prove the keys were never used against clients that do not enforce CT. Until the investigation is published, the useful work is closing those clients off one by one.

Certificates are also getting shorter lives for other reasons, as covered in Let's Encrypt moving to 64-day certificates. Keeping CA bundles, runtimes and certificates current across a fleet is part of our security and compliance work.

Sources: Mozilla security blog, Mozilla dev-security-policy thread with the Chrome Root Program statement, disclosure site with affected certificates and fixed versions, Go issue 82345, Go release history, Sectigo on root CA trust changes