The eMudhra Intermediate CA Compromise: How to Find Affected Certificates in Your Environment

Every padlock in your browser rests on a chain of trust, and that chain is only as strong as the weakest private key in it. This month, eight links in one such chain turned out to be guessable.

Today is October 26, 2026. On October 17, a researcher reported that the private keys behind eight intermediate certificates from eMudhra, a certificate authority (CA), could be recovered. The certificates have been revoked and blocked by the major browser and operating system vendors. The issue is tracked as CVE-2026-111943 and CVE-2026-111944. The urgent work for security teams this week is simple to say and tedious to do: find out whether any of these certificates appear anywhere in your environment, and whether any of your software still trusts them.

A quick refresher on certificate chains

When you visit a website over HTTPS, the server shows a leaf certificate for its own name. That certificate is signed by an intermediate CA, and the intermediate is signed by a root CA. Your browser or operating system ships a list of roots it trusts, called a trust store.

Root keys are kept offline and guarded closely. Intermediates do the daily signing work. The catch is that whoever holds an intermediate's private key can sign a certificate for any name, and clients that trust the chain will usually accept it. That is why a leaked intermediate key is serious even if no bad certificate has been seen yet.

What happened, as reported

According to the public disclosure and the vendor write-ups, the story goes like this:

• During a key generation ceremony on April 30, 2025, eMudhra created keys for 24 subordinate CAs.
• A flaw in a wrap/unwrap step produced a second set of weak P-384 keys. P-384 is an elliptic curve that should give a very large key space.
• Those weak keys were mistakenly used for eight intermediate certificates. Their effective randomness (entropy) was reported at roughly 3 to 8 bits, which means only a few hundred possible keys at most. Recovering them is trivial for a computer.
• Six of the eight are TLS intermediates and two are code-signing intermediates.

The response, again as reported:

• Chrome, Mozilla and Apple blocked the six TLS intermediates. Microsoft blocked the two code-signing intermediates.
• Google removed the emSign ECC Root CA - G3 from the Chrome Root Store, and Mozilla removed trust in the root that signed the intermediates.
• eMudhra revoked the eight certificates and stopped issuing under its G3 root. It states that its root private keys and other intermediates are not affected, that the issue is limited to its global website-security business and not its Indian DSC and eSign services, and that only one of the affected intermediates was used in production, with none issuing certificates to websites or end users.

Treat the vendor's statements as its own account. Your job is not to judge the incident but to confirm your own exposure.

Who should check first

You should put this near the top of the list if you:

• Run internet-facing websites, APIs, VPNs or other TLS services.
• Buy publicly trusted certificates through eMudhra or emSign hierarchies.
• Ship signed software that relies on public code-signing certificates.
• Build or run applications written in Go.
• Look after legacy systems, unmanaged endpoints, appliances or custom trust stores that do not receive distrust updates automatically.

The eight affected intermediates

The SHA-256 fingerprint and serial number are the most reliable ways to match a certificate. Names can be copied; fingerprints cannot.

Certificate	Type	Serial number	SHA-256 fingerprint
EM EV TLS CA - G3B (eMudhra BV)	TLS	c7c41efe92d825f05eae841a4a82c1	E7568FE6E12331F4FD7DE61DA4C7559D0F8EB192A218D4741A3BA75184333838
EM OV TLS CA - G3B (eMudhra BV)	TLS	6cada367fb1c100088120ea202d568	98B896625C0C230ADEEC3EB2CF6AAD5001ECF9156A68644E82374CE5833BC25B
EM DV TLS CA - G3B (eMudhra BV)	TLS	a4aee678f23362b4c0e460b772f214	42C4ACCD12C4F59597925E1A08A7A90102608543809308D50EC427E118BA1493
EM EV TLS CA - G3C (eMudhra Inc)	TLS	8009928a64107601af05fa2f19f109	432EC25F0D28DE9006D97BF752F17BBB2CD41F669933FCB072D9A1148D0261F3
EM OV TLS CA - G3C (eMudhra Inc)	TLS	296926c227a3a1526392b19482a504	CB6E15165AC802E9B3F993F16C25D41F4E81C21EBDE71AE1B012AC00BF9C7C3F
EM DV TLS CA - G3C (eMudhra Inc)	TLS	588b2e3c2bb8cda13e1a1209254321	0164D7CEAE5BB909C272AF151FF44B1177AE9B47D9424B94F1D9558C30934D19
EM OV CS CA - G3B (eMudhra BV)	Code signing	7818933f8f85b4619a2b35fba83d0a	9E39DE2881273ACC225A149C72BA3E0F51424963669AB633EE1DC7DF5DB067B4
EM OV CS CA - G3C (eMudhra Inc)	Code signing	544b7f922c31ae220a4a922916f6e6	4B2460A466F95FD40113BCDCCA2CEB29B3B093921DE45474DA7DF48874C630B1

How to find them: a step-by-step check

There are two sides to the exposure. One is what your servers present. The other is what your software still trusts. The steps below cover both, first with plain open-source tools and then with a commercial scanner for teams that already have one.

Step 1: Make a list of everything that speaks TLS

You cannot check what you have not listed. Pull together your public domains, internal service names, load balancers, VPN gateways and any third-party hosted sites that use your name. Include servers that scanners cannot reach, such as laptops of remote staff and isolated networks. An agent on the host is often the only way to see those.

Step 2: Check the chain each server presents

For any single host, OpenSSL can print every certificate in the chain with its subject, issuer, serial and fingerprint. Replace app.example.com with your own host:

HOST=app.example.com
echo | openssl s_client -connect "$HOST:443" -servername "$HOST" -showcerts 2>/dev/null \
  | awk '/-----BEGIN CERTIFICATE-----/{n++; f=1} f{print > ("chain-" n ".pem")} /-----END CERTIFICATE-----/{f=0}'

for f in chain-*.pem; do
  openssl x509 -in "$f" -noout -subject -issuer -serial -fingerprint -sha256
  echo
done

OpenSSL prints serials in upper case and fingerprints with colons, so compare without caring about case or colons. A quick match against the list of eight:

for f in chain-*.pem; do
  openssl x509 -in "$f" -noout -fingerprint -sha256 | cut -d= -f2 | tr -d ':'
done | grep -i -E 'E7568FE6|98B89662|42C4ACCD|432EC25F|CB6E1516|0164D7CE|9E39DE28|4B2460A4' \
  && echo "MATCH: affected intermediate found" || echo "No affected intermediate in this chain"

The prefixes are only a fast filter. If something matches, compare the full fingerprint against the table before acting. Loop this over your host list for a basic sweep.

Step 3: Search at scale if you run a vulnerability scanner

If your organisation already uses Qualys VMDR with Certificate View, Qualys has published ready-made queries. In Certificate View, a search on issuer name covers all eight:

certificate:(issuer.name:[`EM EV TLS CA – G3B`, `EM OV TLS CA – G3B`, `EM DV TLS CA – G3B`, `EM EV TLS CA – G3C`, `EM OV TLS CA – G3C`, `EM DV TLS CA – G3C`, `EM OV CS CA – G3B`, `EM OV CS CA – G3C`])

A broader check lists every certificate issued under the two eMudhra organisations named on the affected intermediates:

certificate:(issuer.organization:`eMudhra BV` or issuer.organization:`eMudhra Inc`)

Qualys also lists QID 5019897 for affected Go versions and QID 48395, an information-gathered check that enumerates chains containing the eight intermediates. Make sure your agents have the latest signatures before you rely on these. Query tokens are case-sensitive, so check the product help if a query errors. Other scanners will have their own equivalents; the fingerprints in the table work with any tool.

Step 4: Find Go programs that still trust the bad chains

This is the part people miss. Your servers may be clean, but your own applications could still accept a forged certificate. According to the advisories, Go 1.27.3 and 1.26.10 block chains containing any of the eight keys (CVE-2026-111943). Go programs carry their own certificate verification code, so a program built with an older Go keeps the old behaviour until it is rebuilt.

Check the toolchain on build machines:

go version

Check which Go version built a binary you already run:

go version /usr/local/bin/your-service

Anything built with an older release should be rebuilt with a fixed Go version and redeployed. Also apply your operating system vendor's updates, because several distributions ship their own patched Go packages.

Step 5: Replace, update and keep watching

• Replace first. Any leaf certificate whose chain includes one of the eight should be reissued by another trusted CA and redeployed with the correct chain.
• Update. Apply OS security updates and move Go runtimes to the fixed releases.
• Confirm revocation checks work. Revocation only helps clients that actually check it. Custom trust stores, appliances and old Java or embedded systems may need the intermediates removed or explicitly distrusted by hand.
• Keep watching. Save your searches as a scheduled job or dashboard and re-run them after every scan until the results stay clean.

Conclusion

The eMudhra incident is a reminder that trust on the internet depends on two things: the certificates you present and the authorities you choose to trust. The fix is not exotic. List your TLS endpoints, check their chains against eight known fingerprints, rebuild Go programs with a fixed toolchain, and make sure your older systems actually received the distrust. Do it this week, then keep the checks running.

Merits

• The affected certificates are a short, fixed list with exact fingerprints, so matching is precise.
• Major browsers and operating systems have already blocked them, which protects most everyday users automatically.
• Free tools such as OpenSSL and go version are enough for a basic check.
• Existing scanners can turn the search into a repeatable dashboard.
• The exercise improves your certificate inventory for future incidents.

Demerits

• Systems with custom or frozen trust stores do not benefit from vendor blocklists without manual work.
• Go binaries must be rebuilt; updating the toolchain alone does not fix programs already deployed.
• Network scans miss hosts they cannot reach, so agent coverage or manual checks are needed.
• Revocation is unreliable on clients that do not check it.
• Replacing certificates on appliances and third-party hosted sites can take time and vendor help.

Caution

This article is for education and general guidance. Host names such as app.example.com and paths such as /usr/local/bin/your-service are placeholders that you must replace with your own. Details of the incident are summarised from public reports and vendor statements as they stood on the date above and may change; check the latest advisories from your browser, operating system, Go and scanner vendors, and verify every fingerprint against an authoritative source before you act on a match.

Frequently asked questions

• What is the eMudhra intermediate CA compromise? — Eight eMudhra intermediate certificates were created with weak P-384 keys whose private keys could be recovered, so they were revoked and blocked by major vendors in October 2026.
• Which CVEs track this issue? — It is tracked as CVE-2026-111943 and CVE-2026-111944; the Go fix that blocks the affected chains is listed under CVE-2026-111943.
• Are Indian DSC and eSign certificates affected? — eMudhra states the issue is limited to its global website-security business and does not affect its Indian DSC and eSign services.
• How do I check if my website uses an affected intermediate? — Pull the chain with openssl s_client -showcerts, print each certificate's SHA-256 fingerprint, and compare it with the eight fingerprints listed above.
• Why do Go applications need special attention? — Go programs carry their own certificate checks, so they must be rebuilt with Go 1.27.3 or 1.26.10 (or a later fixed release) to reject the affected chains.
• Is revocation enough to stay safe? — Not always, because some clients never check revocation; custom trust stores and older systems may need the certificates removed or distrusted manually.
• What should I do if I find an affected certificate? — Reissue the leaf certificate from another trusted CA, deploy it with the correct chain, and re-scan to confirm the old chain is gone.
• Can I use a vulnerability scanner for this? — Yes; tools such as Qualys Certificate View offer issuer and serial searches, and any scanner that records certificate fingerprints can match the eight listed here.

Tags

#eMudhra #CertificateAuthority #TLS #PKI #CVE2026111943 #CyberSecurity #GoLang #VulnerabilityManagement #CodeSigning #Qualys