eMudhra Intermediate CA Private Key Compromise

• You use a mainstream browser

  Chrome, Firefox, Safari, Edge

  Protected

  Keep the browser and operating system updated. Firefox and Chrome blocked the intermediates within hours of the report.

• You run servers, containers, CI or command-line tools

  Anything with its own trust store: Go, Node.js, Python, Rust, curl, appliances

  Update needed

  Update the system trust store and your runtimes, then rebuild images. Find your fixed version

• Your TLS certificates come from eMudhra

  Chaining to emSign ECC Root CA - G3

  Act now

  Reissue under a different chain or CA. Mozilla and Chrome are removing trust in this root. Details

• You verify code signed through eMudhra

  The two code-signing intermediates

  Low risk

  eMudhra states they never issued a certificate. Treat any signature that chains through them as untrusted.

1. 01

   Update browsers and operating systems

   Firefox users on standard settings were protected on 17 October without updating; the 20 October releases cover users who had disabled remote blocklist updates.
2. 02

   Update the system trust store, then rebuild images

   Install the latest ca-certificates package on servers and rebuild container images on updated base images. An image built before the fix keeps the old trust store until it is rebuilt.
3. 03

   Update runtimes and libraries that bring their own trust store

   Go, Node.js, Python certifi, Rust webpki-roots and others ship their own root bundle or certificate verifier. Check each against the patched versions.
4. 04

   Confirm the root is gone

   Run the offline trust store check against each bundle you rely on.

If you are an eMudhra TLS customer

If any of your certificates chain to emSign ECC Root CA - G3, reissue them now under a different chain or a different CA. eMudhra estimates about 30,000 certificates need migrating, about 97% of them issued through ACME, and says it is moving subscribers to its RSA root, emSign Root CA - G1, which Mozilla is not removing at this time.

Code signing

The two code-signing intermediates were trusted only by Microsoft. eMudhra states they never issued a certificate. Treat any binary whose signature chains through either of them as untrusted.

Operating systems and package managers

Languages, runtimes and libraries

If your software is not listed, check its release notes before assuming it is affected or fixed. The fixes take two forms: Go, rustls-webpki and Electron block the eight compromised intermediates directly, Node.js does that and also updates its root store, and every root bundle above drops emSign ECC Root CA - G3. The curl bundle of 20 October also drops emSign Root CA - C1 and emSign ECC Root CA - C3, which Python certifi and Perl Mozilla::CA keep. Some updates, such as Debian’s, also remove AAA Certificate Services to cut off the Sectigo cross-signed path.

# Prints a line if the bundle still trusts the distrusted root.
# No output means the bundle has been updated.
openssl storeutl -noout -text -certs /path/to/ca-bundle.pem \
  | grep -E "CN ?= ?emSign ECC Root CA - G3"

This check covers the root removal. It does not tell you whether a client honours the intermediate revocations, so a bundle that passes still needs the client software itself to be current.

sudo cp /etc/ssl/cert.pem /etc/ssl/cert.pem.bak &&
awk '/^(###|===) /{skip=0}
  /^=== .*\/CN=(AAA Certificate Services|emSign ECC Root CA - G3)$/{skip=1}
  !skip' /etc/ssl/cert.pem.bak | sudo tee /etc/ssl/cert.pem > /dev/null

sed -i \
  -e 's|^mozilla/emSign_ECC_Root_CA_-_G3.crt|!&|' \
  -e 's|^mozilla/Comodo_AAA_Services_root.crt|!&|' \
  /etc/ca-certificates.conf && update-ca-certificates

d=/etc/pki/ca-trust/source/blocklist; [ -d $d ] || d=/etc/pki/ca-trust/source/blacklist
trust extract --overwrite --format=pem-bundle \
  --filter='pkcs11:object=Comodo%20AAA%20Services%20root;type=cert' \
  $d/Comodo_AAA_Services_root.pem &&
trust extract --overwrite --format=pem-bundle \
  --filter='pkcs11:object=emSign%20ECC%20Root%20CA%20-%20G3;type=cert' \
  $d/emSign_ECC_Root_CA_-_G3.pem &&
update-ca-trust

d=/etc/pki/trust/blocklist; [ -d $d ] || d=/etc/pki/trust/blacklist
trust extract --format=pem-bundle \
  --filter='pkcs11:object=Comodo%20AAA%20Services%20root;type=cert' \
  $d/Comodo_AAA_Services_root.pem &&
trust extract --format=pem-bundle \
  --filter='pkcs11:object=emSign%20ECC%20Root%20CA%20-%20G3;type=cert' \
  $d/emSign_ECC_Root_CA_-_G3.pem &&
update-ca-certificates

trust extract --format=pem-bundle \
  --filter='pkcs11:object=emSign%20ECC%20Root%20CA%20-%20G3;type=cert' \
  /etc/ca-certificates/trust-source/blocklist/emSign_ECC_Root_CA_-_G3.pem &&
update-ca-trust

security.pki.caCertificateBlacklist = [
  "Comodo AAA Services root"
  "emSign ECC Root CA - G3"
];

In our tests, removing AAA Certificate Services did not break connections to current Sectigo-issued sites, because their chains also lead to the USERTrust roots. Older clients that lack those roots could still be affected, so test before rolling the change out widely. For FreeBSD, NetBSD and other platforms, follow your vendor’s guidance; we have not tested a workaround for them.

The private keys of eight intermediate certificate authorities operated by eMudhra can be recovered by anyone from the public certificates alone. Six of the intermediates are for TLS and were trusted by the Apple, Google Chrome, Microsoft and Mozilla root programs. The other two are for code signing and were trusted by Microsoft.

Anyone holding one of the TLS keys could issue a certificate for any domain that a client trusting the chain would accept, which enables interception of TLS traffic. Mainstream browsers were protected within hours of the report. The remaining exposure is software that carries its own trust store and does not check revocation: language runtimes, command-line tools, container images, appliances and embedded devices.

Separately, Mozilla and Chrome are removing trust in the root these intermediates chain to, emSign ECC Root CA - G3. Every certificate issued under that root, including ones unrelated to the compromised keys, will stop working in those clients and has to be reissued under a different chain.

Cause

A P-384 private key should be a random number of roughly 384 bits. According to Mozilla’s analysis, each of the eight affected keys was a number below 256, so all of them can be found by trying 256 candidates. The keys came from a batch of 24 intermediates generated on 30 April 2025; the affected ones are all of the P-384 keys in the B and C series. Mozilla reported that it could not recover the P-384 keys in the other series, and had not yet examined the RSA keys.

eMudhra states that the keys were generated on FIPS 140-2 Level 3 hardware security modules, and that a wrap and unwrap step in the ceremony produced a second, weak set of keys that were then published in place of the strong ones. eMudhra has said it has not yet confirmed the root cause.

1. 2025-04-30

   2025-04-30

   The eight intermediates are created in an eMudhra key generation ceremony.

   Bugzilla comment 5

2. 2026-10-17

   2026-10-17 · 18:05 UTC

   An independent researcher reports recovered private keys to Apple, Google, Microsoft, Mozilla and eMudhra, with signed proof for each key.

   Bugzilla comment 2

3. 2026-10-17 · 21:48 UTC

   Mozilla independently recovers the private keys, confirming the flaw.

   Bugzilla report

4. 2026-10-17 · 22:46 UTC

   Chrome's CRLSet lists the six TLS intermediates as revoked (as observed by the reporter).

   Bugzilla comment 2

5. 2026-10-17 · 22:59 UTC

   Firefox's OneCRL blocklist update completes for all users on standard configurations.

   Mozilla Security Blog

6. 2026-10-18

   2026-10-18 · 09:24 to 09:38 UTC

   eMudhra revokes all eight intermediates with reason cACompromise.

   Bugzilla comment 10

7. 2026-10-19

   2026-10-19 · 14:55 UTC

   Sectigo completes revocation of the eight certificates it had cross-signed for the same keys.

   Bugzilla comment 13

8. 2026-10-20

   2026-10-20

   Mozilla ships Firefox 158.0.1, Firefox ESR 115.43.1 and 153.5.1, and NSS 3.131.1, which removes the affected root.

   Mozilla Security Blog

9. 2026-10-20 · 13:06 UTC

   Mozilla announces emergency removal of trust in emSign ECC Root CA - G3. Chrome commits to the same path at 14:36.

   Bugzilla comment 18

10. 2026-10-20 · 16:27 UTC

    eMudhra confirms it has stopped issuing from every intermediate under emSign ECC Root CA - G3.

    Bugzilla comment 21

The same eight keys were also cross-signed by Sectigo under AAA Certificate Services, a root that Chrome and Mozilla no longer trust but Apple and Microsoft still do. Sectigo revoked those eight cross-certificates on 19 October. Their fingerprints are listed in comment 2 of the Mozilla incident record.

Both can be true: unused intermediates still had valid keys that anyone could have used to sign certificates. Nobody has published evidence that this happened, and nobody can rule it out for clients that do not enforce Certificate Transparency.

Evidence to keep: the date you assessed it, the systems and images you checked, the package versions before and after, and any certificates you reissued.

• Mozilla Bugzilla 2083449The incident record, including the certificate list, timeline and eMudhra’s responses.
• Mozilla Security Blog, 20 October 2026Firefox and NSS releases.
• Chrome Root Program on dev-security-policyChrome’s plan for the root.
• eMudhra press release, 21 October 2026The CA’s account of the cause and scope.
• oss-security mailing listDistribution and open-source coordination.