eMudhra Intermediate CA Private Key Compromise

• You use a mainstream browser

  Chrome, Firefox, Safari, Edge

  Protected

  Keep the browser and operating system updated. Every major browser blocked the intermediates between 17 and 20 October, and CT enforcement means none could have accepted a forged certificate before that.

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

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

  Update needed

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

• You run TLS-inspecting proxies, gateways or appliances

  Egress proxies, API gateways, load balancers, IoT and OT devices

  Update needed

  These validate upstream certificates for every client behind them and often ship a vendor trust store. Check each vendor's update and confirm with the live test below.

• Your TLS certificates come from eMudhra

  Chaining to emSign ECC Root CA - G3

  Act now

  Replace them with certificates from another hierarchy before Chrome removes the root on 27 October. Details

• You verify code signed through eMudhra

  The two code-signing intermediates, trusted on Windows

  Low risk

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

1. 01

   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, and a running process keeps the bundle it loaded at start, so restart services after updating.
2. 02

   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. For Node.js the fix is part of the October 2026 security releases.
3. 03

   Confirm each client rejects the intermediates

   Run the live client test from inside each environment, and the offline checks against every bundle you ship.
4. 04

   Hunt for use of the intermediates in TLS telemetry

   Search certificate logs from network sensors and TLS-inspecting proxies for the six TLS intermediates. Queries below

If you are an eMudhra TLS customer

If any of your certificates chain to emSign ECC Root CA - G3, replace them now with certificates from a different hierarchy. Mozilla has already removed the root from NSS, and Chrome's root store update removing it is expected to reach all devices on 27 October 2026. eMudhra initially estimated about 30,000 certificates needed migrating, about 97% of them issued through ACME, and says it is moving subscribers to its RSA root, emSign Root CA - G1. Chrome says it is also reviewing eMudhra's remaining certificates, so a second hierarchy from a different CA is the safer choice.

Check whether a client still trusts them

The incident tracker runs test hosts that serve certificates from a compromised intermediate, directly and through the Sectigo cross-sign. Run these from the environment you want to test: a server, a CI runner, inside a container. A certificate error means the client is protected.

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

The tracker's page also runs the full set of twelve hosts in a browser, and publishes the chain each host serves for offline testing.

Scan trust stores offline

The first check looks for the distrusted root by name. Most bundles contain only roots, but some applications pin intermediates in their own stores, so the second check matches all sixteen intermediate and cross-sign fingerprints from the Mozilla incident record. No output from either means the bundle is clean.

# Prints a line if the bundle still trusts the distrusted root.
# No output means the root is gone.
openssl crl2pkcs7 -nocrl -certfile /etc/ssl/certs/ca-certificates.crt \
  | openssl pkcs7 -print_certs -noout \
  | grep -F "emSign ECC Root CA - G3"

# Prints the SHA-256 fingerprint and subject of any certificate in the
# bundle that is one of the compromised intermediates or cross-signs.
BUNDLE=/etc/ssl/certs/ca-certificates.crt
cat > /tmp/emudhra-sha256.txt <<'EOF'
E7568FE6E12331F4FD7DE61DA4C7559D0F8EB192A218D4741A3BA75184333838
579480AEA166290BD3C643589E795FC0D0E54E86505D180F1DFF99EFD3199512
98B896625C0C230ADEEC3EB2CF6AAD5001ECF9156A68644E82374CE5833BC25B
5F1DED4DD590AF74631290CF073B122A2AAC6A1FA479778A0BD43579BD832699
42C4ACCD12C4F59597925E1A08A7A90102608543809308D50EC427E118BA1493
45A883F349AEDFD5F3A649B5498FFB121712BA8B448F3F2A91DBC5A766FCDDBE
432EC25F0D28DE9006D97BF752F17BBB2CD41F669933FCB072D9A1148D0261F3
FD9D5C2DBBD4995AB69B8D50C439D9527B00529199C2FD01B2174EB58F07021F
CB6E15165AC802E9B3F993F16C25D41F4E81C21EBDE71AE1B012AC00BF9C7C3F
7485B51C0ED192878FA1D2F948FB529AE1842CC5086C4B67F7BE5B2039DE9489
0164D7CEAE5BB909C272AF151FF44B1177AE9B47D9424B94F1D9558C30934D19
62B7F9868263F72F6911FC78CEAF72C1979158B7368BF648683BB2AA39B02E72
9E39DE2881273ACC225A149C72BA3E0F51424963669AB633EE1DC7DF5DB067B4
A496E23AC0CAB8155FC9B117B97EAE368EFCBB9041AEC8804D5A308D2D01C2D8
4B2460A466F95FD40113BCDCCA2CEB29B3B093921DE45474DA7DF48874C630B1
84112972B8E59D14560AE7E7119654474AAD119990CF3722BFC1E3B91615E1FD
EOF
tmp=$(mktemp -d)
awk -v d="$tmp" '/-----BEGIN CERTIFICATE-----/{n++; f=d "/" n ".pem"}
  n{print > f} /-----END CERTIFICATE-----/{close(f)}' "$BUNDLE"
for f in "$tmp"/*.pem; do
  openssl x509 -in "$f" -noout -fingerprint -sha256 -subject
done | tr -d ':' | grep -iF -A1 -f /tmp/emudhra-sha256.txt
rm -rf "$tmp"

Container images and runtimes

Images carry the trust store they were built with. Check the bundle inside an image without running it, then check runtimes that do not read the system store.

# Checks the trust store baked into a container image without running it.
IMAGE=your-registry/your-image:tag
cid=$(docker create "$IMAGE") &&
docker cp -L "$cid:/etc/ssl/certs/ca-certificates.crt" - | tar -xO \
  | openssl crl2pkcs7 -nocrl -certfile /dev/stdin \
  | openssl pkcs7 -print_certs -noout \
  | grep -F "emSign ECC Root CA - G3"
docker rm "$cid" > /dev/null

# Java: lists emSign entries in the JDK's default trust store.
keytool -list -cacerts -storepass changeit | grep -i emsign

# Python certifi: prints the bundle path to scan with the checks above.
python3 -m certifi

# Node.js: prints any bundled root matching the distrusted root.
node -e 'const { X509Certificate } = require("node:crypto");
for (const pem of require("node:tls").rootCertificates) {
  const c = new X509Certificate(pem);
  if (c.subject.includes("emSign ECC Root CA - G3")) console.log(c.subject);
}'

Match the full name emSign ECC Root CA - G3. Other emSign roots are not part of this incident, and Mozilla is not removing emSign Root CA - G1 at this time. For a custom Java keystore, export it to PEM and run the fingerprint check.

Hunt in TLS telemetry

A forged certificate would be a leaf for a real domain whose issuer is one of the six TLS intermediates, reached either directly or through the Sectigo cross-sign under AAA Certificate Services. Because CT logs now reject these chains and none were logged before the block, it would carry no embedded CT timestamps and would not appear in any CT search. Look for the intermediates by name in certificate logs from network sensors.

# Zeek JSON logs: certificates whose subject or issuer is one of the six
# compromised TLS intermediates. Any hit after 17 October deserves a look.
jq -c 'select(((.["certificate.subject"] // "") + " " + (.["certificate.issuer"] // ""))
  | test("CN=EM (DV|OV|EV) TLS CA - G3[BC]"))' x509.log

# The same check on the leaf issuer recorded per connection.
jq -c 'select((.issuer // "") | test("CN=EM (DV|OV|EV) TLS CA - G3[BC]"))
  | {ts, "id.orig_h", "id.resp_h", server_name, issuer}' ssl.log

• Zeek also records a fingerprint per certificate. Its hash algorithm is configurable, so confirm it is SHA-256 before matching against the fingerprint list.
• Passive sensors only see certificates in TLS 1.2 and earlier. In TLS 1.3 the certificate is encrypted and Zeek writes no x509.log entry. For TLS 1.3 traffic, hunt in the logs of TLS-inspecting proxies, which see the upstream chain, and in client-side logs.
• Prioritise clients that do not enforce CT and talk to high-value endpoints: CI runners pulling dependencies, services calling payment or identity APIs, and devices updating firmware over HTTPS.
• A hit on a test host from the incident tracker is your own check. A hit on any other hostname is worth treating as a possible interception until explained.

Use Certificate Transparency for your own domains

CT cannot reveal a forged certificate used against a non-CT client, but it does answer whether you hold legitimate eMudhra certificates that need replacing, and it is worth keeping as a standing monitor for unexpected issuers on your domains.

# Lists the issuers of every logged certificate for your domain.
# For any eMudhra or emSign issuer, check whether the chain ends at
# emSign ECC Root CA - G3. Those certificates stop working in Chrome on 27 October.
curl -s 'https://crt.sh/?q=example.com&output=json' \
  | jq -r '.[].issuer_name' | sort | uniq -c | sort -rn

Operating systems and package managers

Languages, runtimes and libraries

The fixes take two forms. Go, rustls-webpki and Electron block the eight intermediates directly; Node.js does that and also updates its root store; every root bundle above drops emSign ECC Root CA - G3. Some updates, such as Debian's and Ubuntu ESM's, also remove AAA Certificate Services to cut off the Sectigo cross-signed path. If your software is not listed, check its release notes and run the live client test.

sudo cp -p /etc/ssl/cert.pem /etc/ssl/cert.pem.bak &&
sudo 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

apk add ca-certificates &&
sed -i -e 's|^mozilla/emSign_ECC_Root_CA_-_G3.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"
];

cp /etc/ssl/certs/14bc7599.0 /usr/share/certs/untrusted/14bc7599.pem
cp /etc/ssl/certs/ee64a828.0 /usr/share/certs/untrusted/ee64a828.pem
certctl rehash

certctl untrust /usr/share/certs/mozilla/all/emSign_ECC_Root_CA_-_G3.pem &&
certctl untrust /usr/share/certs/mozilla/all/Comodo_AAA_Services_root.pem

Removing AAA Certificate Services closes the cross-signed path on systems that still trust that root. Older clients may rely on it for other Sectigo chains, so roll the change out gradually and watch for new certificate errors.

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, Chrome, Microsoft and Mozilla root programs. The other two are for code signing and were trusted by Microsoft. Chrome did not need to block those two, because it will not build a TLS path through a CA restricted to code signing.

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. The same eight keys were also cross-signed by Sectigo under AAA Certificate Services, a root that Chrome and Mozilla had already dropped but Apple and Microsoft still trust.

Because the keys cannot be un-leaked, Mozilla and Chrome are also removing trust in the root these intermediates chain to, emSign ECC Root CA - G3. Every certificate issued under that root, including legitimate ones, stops working in those clients and has to be reissued.

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. One key published after disclosure was the number 4. 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.

eMudhra states that the keys were generated on FIPS 140-2 Level 3 hardware security modules, and that an approved deviation in the ceremony to test a wrap and unwrap step produced a second, weak set of keys. Because the key labels were similar, the weak keys were used by mistake to create the certificate requests, including the ones sent to Sectigo for cross-signing. eMudhra says it has not yet confirmed the exact root cause and will re-verify every key ceremony it has run.

Fingerprints are copied from the Mozilla incident record. Mozilla also publishes them as impacted-intermediates.json for trust store operators.

1. 2025-04-30

   2025-04-30

   eMudhra creates the eight intermediates in a key generation ceremony. From this point the keys can be recovered by anyone.

   Bugzilla comment 5

2. 2026-10-17

   2026-10-1718:05 UTC

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

   Google Security Blog

3. 2026-10-1719:45 UTC

   Chrome lands a CRLSet update that blocks the public keys of the six TLS intermediates, which also covers the Sectigo cross-signs.

   Google Security Blog

4. 2026-10-1720:06 UTC

   The report reaches Mozilla's certificates address, forwarded by the Chrome Root Program.

   Bugzilla 2083449

5. 2026-10-1721:48 UTC

   Mozilla independently recovers the private keys, confirming the flaw.

   Bugzilla 2083449

6. 2026-10-1722:59 UTC

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

   Mozilla Security Blog

7. 2026-10-18

   2026-10-1809:24 to 09:38 UTC

   eMudhra revokes all eight intermediates with reason cACompromise.

   Bugzilla comment 10

8. 2026-10-19

   2026-10-19

   Apple platforms block the intermediates. The issue is disclosed to downstream trust store operators.

   Incident tracker

9. 2026-10-19

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

   Bugzilla comment 13

10. 2026-10-1922:00 UTC

    Android devices receive an equivalent block through Google Play Services. The time is approximate.

    Google Security Blog

11. 2026-10-20

    2026-10-20

    Microsoft ships blocks through Windows automatic certificate trust list updates.

    Incident tracker

12. 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 root.

    Mozilla Security Blog

13. 2026-10-20

    Mozilla announces emergency removal of trust in emSign ECC Root CA - G3, Chrome commits to the same, and eMudhra stops issuing from every intermediate under that root.

    Bugzilla comments 18 to 21

14. 2026-10-21

    2026-10-2108:29 UTC

    Mozilla releases Firefox for Android 158.0.2 to fix clients that did not apply the bundled blocklist at startup.

    Mozilla Security Blog

15. 2026-10-27

    2026-10-27

    Planned: the Chrome Root Store update that removes emSign ECC Root CA - G3 reaches all devices, on Tuesday morning Pacific time.

    Google Security Blog

Both can be true. Unused intermediates still had keys anyone could use to sign certificates, and a forged certificate does not need the CA's infrastructure. Nobody has published evidence that this happened, and nobody can rule it out for clients that do not enforce Certificate Transparency.

• Mozilla Bugzilla 2083449The incident record: certificate list, fingerprints, timeline and eMudhra's responses.
• Google Security Blog, 20 October 2026Chrome and Android response, Certificate Transparency findings and the root removal date.
• Mozilla Security Blog, 20 October 2026OneCRL, Firefox and NSS releases, and the 21 October Android fix.
• Mozilla dev-security-policy threadGuidance for trust store operators and the Chrome Root Program's statement.
• Incident tracker by Mozilla's Dennis JacksonClient test hosts, patched versions, and workarounds per platform.
• eMudhra press release, 21 October 2026The CA's account of the cause and scope.
• eMudhra incident updateThe CA's statement on production use and customer impact.
• Cloudflare Blog, 20 October 2026How a large operator prioritised proxies, origins and base images.
• Zeek x509.log referenceCertificate fields available to network sensors, and the TLS 1.3 limit.
• oss-security mailing listOpen-source distribution coordination.