eMudhra generated CA keys anyone could compute: update every trust store, replace emSign ECC G3 certificates

What happened

On October 17, 2026, a researcher identified as Wayne reported to the Apple, Chrome, Microsoft and Mozilla root programs, and to eMudhra, that he held the private keys of eight eMudhra intermediate certificate authorities, with signed proof for each. He had found the weak keys less than two hours earlier while running checks over CA certificates disclosed in the CCADB, the database the root programs share. Mozilla confirmed the proof and, without knowing the reporter's method, derived the keys itself less than two hours after the report reached it. eMudhra, an Indian CA that sells TLS certificates under the emSign brand, revoked the eight certificates on October 18 with the reason caCompromise. Mozilla tracks the incident as "eMudhra: Private key compromise of Intermediate Certificates" (bug 2083449). Mozilla's Dennis Jackson also publishes a public incident tracker with the affected certificates, test hosts and a list of fixed software, cited below as the incident tracker.

The keys were not stolen. They were generated so badly that anyone can compute them from the public certificates, and anyone holding a CA key can issue a certificate for any domain. An on-path attacker could use such a certificate against any client that still trusts the chain. Browsers blocked the intermediates within hours. The long tail is everything else that validates TLS: language runtimes, package managers, command-line tools, appliances and container images, many of which ship their own copy of the root list and do not check revocation.

What was wrong with the keys

A P-384 private key should be a random number of up to 384 bits. All eight affected keys were integers smaller than 256. In the words of Mozilla's Dennis Jackson, they are "effectively all-zeroes apart from the last byte", which makes them recoverable almost instantly. BleepingComputer, which checked a key that a researcher later published, reports that the key of EM OV TLS CA - G3C is the number 4. Mozilla also reported that local AI agents recovered the keys on their first attempt. By October 20, several people had derived the keys independently and some had said so publicly; Mozilla cited this when it decided to remove the root as well as block the intermediates.

eMudhra's preliminary explanation, posted to the Mozilla bug on October 19: during its April 30, 2025 key ceremony, an approved deviation to test key wrap and unwrap for export ran flawed code that created a second, weak key pair on the hardware security module next to each intended strong key. Because the key labels were similar, the weak keys were used by mistake to create the certificate signing requests, which eMudhra's root signed and which were also sent to Sectigo for cross-signing. eMudhra says the RSA keys from the same ceremony took a different path and are not affected, and that the HSMs do not appear to be at fault. Its October 21 press release says it is still working to establish the root cause.

There was an earlier signal. In June 2025, Mozilla bug 1970728 recorded invalid CRL signatures for the same six TLS intermediates. eMudhra now says those CRLs were signed with the intended strong keys, failed to verify, and were then re-signed with the weak keys that matched the certificates. The Chrome Root Program has asked eMudhra why it did not stop and revoke at that point, and why its 2025 incident report did not mention two key pairs per CA.

Timeline (UTC)

1. April 30, 2025eMudhra's key ceremony creates 24 intermediates; the eight P-384 keys of its B and C series are weak (Mozilla, eMudhra).
2. May 14, 2025Sectigo cross-certificates for the same eight keys become valid (incident tracker, Chrome Root Program).
3. June 5, 2025Mozilla bug 1970728 opens over invalid CRL signatures on the six TLS intermediates; eMudhra later re-signs the CRLs with the weak keys (Chrome Root Program, eMudhra).
4. October 17, 202616:27 the reporter's scan of CA certificates disclosed in CCADB finds the weak keys; 18:05 report with proof to the four root programs and eMudhra; 19:45 Chrome CRLSet block; 21:48 Mozilla derives the keys independently; 22:59 Mozilla OneCRL block complete (reporter, Chrome, Mozilla).
5. October 18, 202609:24 to 09:38 eMudhra revokes the eight intermediates; Mozilla opens bug 2083449 (eMudhra, Mozilla).
6. October 19, 2026Sectigo revokes its cross-certificates; Apple devices block the intermediates (incident tracker); Android update through Google Play Services around 22:00 (Chrome); Mozilla starts notifying downstream trust stores; webpki-roots 1.0.10 drops the root.
7. October 20, 2026Mozilla announces emergency removal of emSign ECC Root CA - G3 and removes it from NSS, Chrome commits to the same, eMudhra stops issuing under the root; Firefox 158.0.1 and ESR updates; Microsoft platforms block (incident tracker); certifi, uv and Go fixes.
8. October 21, 2026OpenJDK advisory, Red Hat bulletin RHSB-2026-012 and Node.js releases; Firefox for Android 158.0.2; Chrome publishes twelve questions to eMudhra.
9. October 27, 2026Planned: the Chrome Root Store removal reaches all devices that rely on it, on Tuesday morning US Pacific time (Chrome).

Which certificates and roots are affected

The eight intermediates were created for eMudhra's European (eMudhra BV) and US (eMudhra Inc) operations. eMudhra says seven were never used in production and the eighth issued no end-entity certificates.

• TLS, issued by emSign Root TLS CA - G3: EM DV TLS CA - G3B, EM OV TLS CA - G3B, EM EV TLS CA - G3B, EM DV TLS CA - G3C, EM OV TLS CA - G3C and EM EV TLS CA - G3C. Mozilla says these six were trusted by all four major root programs.
• Code signing, issued by emSign Root CS CA - G3 and trusted by Microsoft: EM OV CS CA - G3B and EM OV CS CA - G3C.
• Sectigo cross-certificates: each of the eight keys also has a certificate issued by Sectigo's AAA Certificate Services, valid from May 14, 2025. Sectigo revoked all eight on October 19.
• Root emSign ECC Root CA - G3, SHA-256 86A1ECBA089C4A8D3BBE2734C612BA341D813E043CF9E8A862CD5C57A36BBE6B, included by Apple, Chrome, Microsoft and Mozilla before this incident. The TLS chains run through a cross-certificate: EM ... TLS CA - G3B or G3C, then emSign Root TLS CA - G3, then emSign ECC Root CA - G3. Microsoft also includes emSign Root TLS CA - G3 and emSign Root CS CA - G3 directly as roots (incident tracker's roots.json and test chains).
• Root AAA Certificate Services (Comodo AAA Services root in Linux stores), SHA-256 D7A7A0FB5D7E2731D771E9484EBCDEF71D5F0C3E0A2948782BC83EE0EA699EF4. Chrome and Mozilla removed it earlier; Apple and Microsoft still include it, according to Sectigo. Debian distrusts it in its fix, and Red Hat recommends blocklisting it together with the emSign root.

Fingerprints and serial numbers for all 16 certificates are in impacted-intermediates.json on the incident tracker. Not affected, as far as the primary sources say: emSign Root CA - G1, which Mozilla is not removing "at this time"; eMudhra's A and A-1 series intermediates, whose keys Mozilla could not recover; and other CAs, since Chrome says no other key in its root store shares this failure mode.

What each root program did

• Chrome blocked the public keys of the six TLS intermediates through a CRLSet at 19:45 UTC on October 17, without needing a browser update or restart; blocking by key also covers the Sectigo cross-certificates. Android devices got the equivalent update through Google Play Services around 22:00 UTC on October 19. Chrome removed emSign ECC Root CA - G3 from the Chrome Root Store, a change expected to reach all devices that rely on that store on the morning of October 27, 2026 (US Pacific time), and earlier on Canary and Beta. Chrome is also reviewing whether eMudhra's remaining CA certificates stay included.
• Mozilla blocked the intermediates in OneCRL at 22:59 UTC on October 17 and delivered the list through Remote Settings the same day. It removed emSign ECC Root CA - G3 from NSS on October 20 and shipped Firefox 158.0.1, Firefox ESR 153.5.1 and Firefox ESR 115.43.1 that day with the blocklist built in, for installations that cannot reach Remote Settings. Firefox for Android 158.0.2 followed on October 21 after some Android profiles failed to apply the list. Mozilla asked eMudhra to stop issuing under the G3 root; eMudhra says it stopped on October 20.
• Apple corroborated the report on October 17, according to the reporter's timeline, and the incident tracker says Apple devices have blocked the intermediates since October 19. We found no Apple announcement and no statement on whether Apple will remove the root.
• Microsoft shipped blocks through the automatic certificate trust list updates in Windows, and Microsoft platforms have blocked the intermediates since October 20, according to the incident tracker. We found no Microsoft announcement. Windows machines that do not receive those updates, such as offline systems, stay exposed until the certificates are blocked locally.
• The CAs: eMudhra revoked the eight intermediates between 09:24 and 09:38 UTC on October 18, and Sectigo revoked the cross-certificates on October 19. Revocation alone does not close this. Mozilla notes that many endpoints have no effective way to get revocation information, which is why it removed the root.

Who was exposed, and how to look for misuse

The keys could be computed from April 30, 2025, when the certificates were created, until each client stopped trusting them. Chrome says no TLS certificate chaining to the six TLS intermediates was logged to Certificate Transparency before its block, so CT-enforcing clients could not have been attacked with them. That covers Chrome, Android apps that target the latest SDK or opt in to CT enforcement (Chrome), and Firefox, Edge and Safari (incident tracker). Most other TLS clients do not enforce CT: curl, Python, Go, Java and Node.js programs, mobile and IoT libraries, and most server-to-server traffic. For those, the tracker states that it is not known whether anyone exploited the flaw.

A forged certificate used against a client that does not enforce CT never has to appear in a public log, so a CT search cannot rule out misuse. If you keep TLS metadata, such as Zeek x509 logs or records from TLS-inspecting proxies, search back to April 2025 for certificates issued by any of the eight intermediates, or for chains that contain one of their public keys; the SPKI hashes are in impacted-intermediates.json. Expect hits from the incident tracker's test hosts if anyone on your network ran its check, since those hosts serve these chains on purpose.

Check your TLS clients

Test each runtime and image, not only the host. A client that rejects the tracker's test hosts no longer trusts the compromised chains; the -aaa host tests the Sectigo cross-certificate path.

# 1. Does this client still trust the compromised chains?
#    curl exit code 60 (certificate problem) is the result you want.
#    "STILL TRUSTS" means this client needs an update; other errors are inconclusive.
curl -sS -o /dev/null https://dv-g3b-emudhra.we-have-a-problem.com/ && echo "STILL TRUSTS: emSign chain"
curl -sS -o /dev/null https://dv-g3b-aaa-emudhra.we-have-a-problem.com/ && echo "STILL TRUSTS: Sectigo cross-sign"

#    Repeat through each runtime you ship. Fixed clients raise a certificate error.
python3 -c "import requests; requests.get('https://dv-g3b-emudhra.we-have-a-problem.com/'); print('STILL TRUSTS')"
node -e "fetch('https://dv-g3b-emudhra.we-have-a-problem.com/').then(()=>console.log('STILL TRUSTS'),e=>console.log('rejected:',e.cause&&e.cause.code))"

# 2. Versions of the bundled trust stores
python3 -m pip --version                                 # fixed: 26.2.2 or later
python3 -c "import certifi; print(certifi.__version__)"  # fixed: 2026.10.19 or later
uv --version                                             # fixed: 0.13.4 or later
go version                                               # fixed: go1.26.10, go1.27.3 or later
node --version                                           # fixed: 22.23.4, 24.22.1, 26.12.1 or later

# 3. Is the removed root still in a store? Other emSign roots, such as G1, are not affected.
awk -v cmd='openssl x509 -noout -subject' '/BEGIN CERT/{close(cmd)};{print | cmd}' \
  /etc/ssl/certs/ca-certificates.crt | grep "emSign ECC Root CA - G3"
keytool -list -v -cacerts -storepass changeit \
  | grep -E "^Owner: .*CN=(emSign ECC Root CA - G3|AAA Certificate Services)"
#    Heuristic sweep: finds labelled PEM bundles and root stores inside binaries
#    (certifi, Java keystores, NSS). Review each hit; a file in a blocklist directory is the fix.
grep -rl "emSign ECC Root CA - G3" /usr /opt /etc /srv 2>/dev/null

Check each trust store separately. On one Ubuntu 24.04 host we tested on October 22, the fixed ca-certificates package (20260816ubuntu0.24.04.1) had removed the root from /etc/ssl/certs, but the Java keystore /etc/ssl/certs/java/cacerts had not been regenerated: it still contained emSign ECC Root CA - G3 and the AAA root, and OpenJDK 21 on that host still connected to both test hosts. On Debian and Ubuntu, sudo update-ca-certificates --fresh rebuilds the Java keystore from /etc/ssl/certs and drops entries that are no longer there; run the keytool check again afterwards.

What to update

• Browsers: keep Chrome and Edge current; Firefox 158.0.1, Firefox ESR 153.5.1 or ESR 115.43.1, and Firefox for Android 158.0.2. Restarting an Android device pulls the Google Play Services update at once (Chrome).
• Linux trust stores: Ubuntu ca-certificates 20260816ubuntu0.22.04.1, 20260816ubuntu0.24.04.1, 20260816ubuntu0.26.04.1 or 20260816ubuntu0.26.10.1; Ubuntu 20.04 and older showed no fix in Launchpad on October 22. Debian 20250419~deb12u2 (bookworm), 20250419+deb13u1 (trixie) or 20260816+nmu1 (forky, sid). Red Hat's bulletin RHSB-2026-012 lists RHEL 6 to 10 as affected and gives blocklisting the two roots as the mitigation; it listed no fixed package versions when we checked on October 22. The incident tracker lists fixed packages for Alpine (20261020-r0), Arch, Fedora, Gentoo, FreeBSD and others.
• macOS: Apple blocks the intermediates, but the built-in curl, git, python3, perl, ruby and openssl verify against /etc/ssl/cert.pem without checking revocation, and that file had not been updated. The incident tracker gives a workaround.
• Windows: confirm that automatic root and disallowed-certificate updates reach every machine. Isolated systems need the 16 certificates blocked through your own management tooling.
• Python: pip 26.2.2, certifi 2026.10.19, uv 0.13.4, pixi 0.82.1 and sigstore 4.5.1, per the Python security notice on discuss.python.org; GitHub rates the certifi and uv advisories (GHSA-6q48-6c7w-9gw2, GHSA-hq85-5cpj-mr62) critical. According to the notice, pip always loads its vendored certifi in addition to the system store, so an OS update does not fix pip. certifi 2026.10.18 removed all emSign roots; 2026.10.19 restored the unaffected ones, so take 2026.10.19 or later. The Python.org macOS installer also uses certifi. The notice includes a hash-pinned command that upgrades pip without relying on the old bundle.
• Go 1.27.3 or 1.26.10 (CVE-2026-111943) add a denylist for the intermediates in crypto/x509. Go uses the system roots on most platforms, so update the OS store as well.
• Java: OpenJDK's October 21 advisory (CVE-2026-91403) lists 27.0.1, 25.0.5, 21.0.13, 17.0.21, 11.0.33, 8u512 and earlier as affected. Update standalone runtimes; if you cannot, replace lib/security/blocked.certs with the file OpenJDK provides, or enable revocation checking. According to OpenJDK, the OpenJDK packages of Debian, Ubuntu, Red Hat, Fedora, Arch, Gentoo and Oracle Linux use the OS store, while FreeBSD and Homebrew builds must be updated directly; still run the keystore check above, for the reason given there.
• Node.js 22.23.4, 24.22.1 or 26.12.1; the 24.22.1 release notes say it updates the bundled root certificates to NSS 3.131.1. Electron 44.9.1, 43.8.1 or 42.11.16, and Deno 2.9.8. Bun had no fix on the incident tracker on October 22.
• Rust: webpki-roots and webpki-root-certs 1.0.10, rustls-webpki 0.103.16. These are compiled in, so rebuild and redeploy the binaries.
• Other bundles on the incident tracker: curl's CA extract of 2026-10-20, Composer ca-bundle 1.4.16 or 1.6.0, Perl Mozilla::CA 20261020 and Elixir castore 1.0.22. Erlang certifi and Bottlerocket were still pending.
• Containers: rebuild images instead of relying on host updates. An image keeps the bundle it was built with, and scratch or distroless images that copy a CA file at build time never see OS updates. Run the checks above inside each rebuilt image.

If you serve emSign certificates

According to eMudhra, the compromised intermediates issued no end-entity certificates, so legitimate sites do not use them. For site operators, the problem is the root. Certificates from unaffected intermediates under emSign ECC Root CA - G3 lose trust as the root disappears: already in clients that use updated Mozilla-derived bundles (certifi, uv, webpki-roots, Debian and Ubuntu ca-certificates, NSS 3.131.1 and the runtimes built on them), and in Chrome when the root store change is expected to ship on October 27. We found no announced root removal from Apple or Microsoft, so expect such a site to work on some clients and fail on others.

By the Chrome Root Program's CT count on October 21, about 30,800 unexpired certificates chain to the G3 root. 30,791 (99.9%) came from two Internet2 InCommon subordinate CAs, InCommon Intermediate CA - OVG3C and InCommon Intermediate CA - DVG3C, and 18 from eMudhra's own CAs: EM EV TLS CA - G3A-1, EM OV TLS CA - G3A-1, emSign ECC SSL CA - G3, emSign ECC EV SSL CA - G3 and emSign TLS CA - G3. eMudhra estimates that about 30,000 certificates need migration, about 97% of them issued through ACME.

# Which chain does an endpoint serve? Read the i: (issuer) lines.
HOST=your.host.example
echo | openssl s_client -connect "$HOST:443" -servername "$HOST" 2>/dev/null \
  | grep -E '^ *[0-9]+ s:|^ +i:'
# Affected if an issuer is InCommon Intermediate CA - OVG3C or DVG3C,
# an EM ... G3 or emSign ... G3 CA, or emSign ECC Root CA - G3.

• Find the certificates: check what each endpoint serves with the command above, and search Certificate Transparency for your domains to catch endpoints missing from your inventory.
• Reissue from a hierarchy that does not chain to emSign ECC Root CA - G3 before October 27. InCommon says RSA certificates are not affected and can be issued immediately through CertiNext, and asks subscribers to reissue affected certificates as RSA until ECC issuance is restored. eMudhra told Mozilla it is moving subscribers to its RSA root, emSign Root CA - G1; its later statements mention an "alternate, independently operated" hierarchy, and Chrome has asked which one it means.
• ACME: a client does not renew before its normal window unless the CA signals it through ACME Renewal Information or you force a renewal. Force it, and if you move from ECC to RSA, change the key type in the client configuration first. Chrome raised both points with eMudhra.
• Deploy the complete new chain, reload every TLS terminator (load balancers, CDNs, ingress controllers, appliances), and verify from a client with an updated store, for example curl on a patched Ubuntu host or Python with certifi 2026.10.19.
• Update pins and private trust lists: mobile apps, IoT firmware, mutual-TLS configurations and partner integrations that pin an emSign G3 root or intermediate must change before the certificate does.
• Our view: Chrome is reviewing whether eMudhra's remaining CA certificates stay in its store. If eMudhra is your only CA, set up a second ACME CA from another operator now, so that a further distrust decision does not become an outage.

What this incident shows

Browsers enforce Certificate Transparency and receive revocation pushes, and they were protected within hours. The remaining exposure is in the rest of the stack, where each runtime, package manager and image carries its own snapshot of the root list and rarely checks revocation. Teams that run TLS clients need an inventory of those trust stores and a way to update all of them at once; this incident is the test of whether they have one.

For teams that run their own PKI, the lesson is in the June 2025 CRL failure. A signing key that does not match its certificate is a key-management incident. Checking after each ceremony that every issued certificate carries the public key you meant to generate, and that every signed object verifies before it is published, would likely have caught this one in 2025.

Sources

1. Mozilla Bugzilla 2083449: eMudhra: Private key compromise of Intermediate Certificates
2. Mozilla Bugzilla 2084101: Remove eMudhra emSign Root CA - G3 from NSS
3. Mozilla Bugzilla 1970728: eMudhra: Invalid CRL signatures (2025)
4. Mozilla dev-security-policy: Compromised eMudhra Intermediate Certificates
5. Chrome and Android Security Teams: Protecting Chrome and Android Users from Compromised eMudhra Intermediate CA Certificates (October 20, 2026)
6. eMudhra Intermediate CA Compromise: incident tracker published by Dennis Jackson (Mozilla)
7. Incident tracker: impacted-intermediates.json
8. Incident tracker: roots.json
9. Incident tracker test host: EM DV TLS CA - G3B via emSign Root TLS CA - G3
10. Incident tracker test host: EM DV TLS CA - G3B via the Sectigo AAA cross-certificate
11. eMudhra: Statement on Recent Certificate Security Incident
12. eMudhra press release (October 21, 2026)
13. GitHub Advisory GHSA-6q48-6c7w-9gw2: certifi bundles emSign root CAs with compromised intermediate CA keys
14. GitHub Advisory GHSA-hq85-5cpj-mr62: uv's bundled CA store trusts an emSign root whose intermediate CA keys are compromised
15. uv 0.13.4 release notes
16. discuss.python.org (Seth Larson): Information for Python users regarding the eMudhra/emSign CA certificate security incident
17. CVE-2026-111943 (Go crypto/x509)
18. golang-announce: Go 1.27.3 and Go 1.26.10 security release
19. OpenJDK Vulnerability Advisory 2026/10/21 (CVE-2026-91403)
20. Mozilla MFSA 2026-111: Firefox 158.0.1
21. Mozilla MFSA 2026-112: Firefox ESR 153.5.1
22. Mozilla MFSA 2026-113: Firefox ESR 115.43.1
23. Mozilla MFSA 2026-116: Firefox for Android 158.0.2
24. Red Hat RHSB-2026-012: Certificate compromise - eMudhra (CVE-2026-111943)
25. Debian security tracker: ca-certificates
26. Ubuntu Launchpad bug 2171507: ca-certificates update tracking bug
27. Node.js v24.22.1 release notes
28. rustls webpki-roots 1.0.10 release
29. InCommon Certificate Service (service notice)
30. BleepingComputer: Mozilla, Google, Apple block compromised eMudhra CA certificates (secondary)
31. GitHub Advisory DatabaseContains data from the GitHub Advisory Database, licensed CC-BY 4.0.