eMudhra's guessable CA keys: what happened and how to check your estate

What happened

A certificate authority (CA) is trusted to vouch for websites and software publishers. That trust rests on one thing: nobody else can use the CA’s private key.

On 17 October 2026 an independent researcher reported that eight intermediate CA certificates from eMudhra, an Indian CA, had private keys with values below 256. A healthy P-384 key is a random number around 115 digits long. These could be found by trying at most 256 values, and one of them was literally the number 4.

eMudhra attributes it to a faulty script in an April 2025 key ceremony. The script produced a second, weak set of keys with labels similar to the real ones, and the weak ones were picked. The certificates were valid for about 17 months before anyone noticed. eMudhra says only one intermediate reached production and none issued customer certificates. Nobody can prove the keys were not used by someone else in that window.

Six of the intermediates could issue TLS certificates and two could issue code-signing certificates. With any of those keys, an attacker could mint a certificate for any domain, or sign malware, and it would chain to a trusted root.

Timeline

Mozilla also removed trust in the root that signed the intermediates, and Google removed emSign ECC Root CA – G3 from the Chrome Root Store. The issue is tracked as CVE-2026-111943.

Why browsers being fixed is not enough

Browsers update their trust decisions centrally and fast. A lot of software does not:

• Containers and base images carry a frozen ca-certificates bundle from when they were built.
• Language runtimes with their own trust store, for example Python’s certifi, Node.js and Bun, Java cacerts, and Go before 1.27.3 and 1.26.10.
• Tools that don’t check revocation. macOS’s /usr/bin/curl is a documented example.
• Appliances, IoT and embedded devices that rarely get updates.

For those, a revoked intermediate is still a valid one until the bundle is updated.

What to do

1. Patch the trust stores: OS updates, ca-certificates, NSS 3.131.1, Electron 44.9.1, Go 1.27.3 or 1.26.10, and runtime updates as they ship.
2. Rebuild container images instead of only restarting them.
3. If you are an eMudhra TLS customer, plan to replace your certificates with another CA.
4. Hunt for the affected intermediates in places that matter to you, using the checks below.

Affected intermediates

Fingerprints as published by Qualys. Verify against the CCADB before blocking.

Checks and hunting queries

Which emSign roots does this Linux host or image trust?

awk -v cmd='openssl x509 -noout -subject' \
  '/BEGIN CERT/{close(cmd)} {print | cmd}' /etc/ssl/certs/ca-certificates.crt | grep -i emsign

Python’s certifi bundle (used by requests):

grep -c "emSign" "$(python3 -m certifi)"

Windows root store:

Get-ChildItem Cert:\LocalMachine\Root, Cert:\LocalMachine\CA |
  Where-Object Subject -match 'emSign|EM (DV|OV|EV) TLS CA|EM OV CS CA' |
  Select-Object Subject, Thumbprint, NotAfter

Do any of your endpoints serve a chain through these intermediates?

for h in $(cat hosts.txt); do
  openssl s_client -connect "$h:443" -servername "$h" -showcerts </dev/null 2>/dev/null |
    grep -qE 'i:.*EM (DV|OV|EV) TLS CA . G3[BC]' && echo "$h"
done

Network telemetry (Zeek): certificates seen on the wire issued by the affected CAs.

zeek-cut ts certificate.subject certificate.issuer < x509.log |
  grep -E 'EM (DV|OV|EV) TLS CA . G3[BC]'

Code signed by the affected intermediates (Microsoft Defender for Endpoint, KQL):

DeviceFileCertificateInfo
| where Timestamp > ago(90d)
| where Issuer has "EM OV CS CA"
| summarize Devices = dcount(DeviceId), Files = make_set(SHA1, 20) by Signer, Issuer

A hit is not proof of compromise, but any binary signed through these intermediates deserves a closer look.

Takeaways

• Key generation is part of your attack surface. A ceremony script is code, and code needs tests: a simple check of key size and randomness would have caught this.
• Inventory where your trust stores live, not just which certificates you own.
• Certificate Transparency and public root programs worked. Someone outside the CA found the problem by reading public data.

Sources

• Help Net Security: eMudhra security blunder left trusted CA signing keys exposed
• BleepingComputer: Mozilla, Google, Apple block compromised eMudhra CA certificates
• BleepingComputer: Microsoft releases Windows OOB updates to distrust eMudhra certificates
• Qualys: How to identify compromised eMudhra certificates
• The Hacker News: eMudhra to exit global SSL/TLS business
• eMudhra: statement on the certificate security incident