eMudhra CA Key Compromise Explained: Weak Keys, Not a Data Breach

The eMudhra incident is not a data breach. Eight intermediate CA private keys were generated so weakly that anyone could compute them from public certificates; one was the number 4. Browsers blocked them within hours. The remaining risk sits in servers, containers and devices with their own CA bundles, which need updates, rebuilds and a real test.

What happened

eMudhra is an Indian certificate authority that also runs a Global TLS business issuing website certificates. In April 2025 it created a set of intermediate CA certificates under its ECC root, the emSign ECC Root CA G3. Eight of those intermediates (six for TLS, two for code signing) ended up with private keys that were tiny integers instead of large random numbers.

On 17 October 2026 a researcher, credited by Mozilla and Google only as Wayne, reported this to the browser root programs with proof that he held the keys. Mozilla says it recovered the keys independently the same day. Scott Helme later published the recovered values: one key is 4, others include 56, 115, 155, 156, 230 and 237.

Nobody had to break into anything. As The Hacker News noted in a correction on 21 October, the keys were not stolen; they could simply be calculated from the certificates. eMudhra told PSU Watch there was no unauthorised access to its infrastructure and no breach of customer data.

Two counts circulate. Google's post talks about eight subordinate CAs but says six intermediates had no certificates in Certificate Transparency (CT). The difference is the two code-signing intermediates, which Chrome's TLS verifier will not build a path through, according to The Hacker News.

Why a key like the number 4 matters

Elliptic curve keys work like this. The private key is a number. The public key is a fixed, publicly known starting point on the curve, combined with itself that many times. Going forward is cheap. Going backward, from public key to private key, is meant to be impractical.

That one-way property only holds when the private key is a huge random number. A P-384 key should be a random 384-bit value, which The Register puts at roughly 10 to the power of 115 possibilities. Mozilla's analysis found that all eight eMudhra keys were below 256. A laptop checks that many values in well under a second, which is what Helme reported.

So the question was never whether an attacker could get the keys. Anyone could. The real questions are whether anyone used them in the roughly 17 months Helme counts from April 2025 to October 2026, and which software would have believed a forged certificate.

With an intermediate CA key, someone can sign a certificate for any domain and most clients will accept it as long as they trust the chain. For the code-signing pair, CERT-In warns the risk is malware signed to look trusted.

On abuse, the evidence is reassuring but limited. Google says no TLS certificate chaining to the six web intermediates was logged in CT before the block, so forged certificates could not have worked against CT-enforcing clients such as Chrome. Cloudflare says it found no active exploitation on its services. CERT-In says public disclosures as of 21 October do not confirm malicious exploitation. Helme's caution still applies: for clients that never check CT, there is no way to be sure.

What eMudhra and CERT-In said

eMudhra's account, as reported by The Hacker News, PSU Watch, CERT-In and its comments on Mozilla's bug tracker, is preliminary. It says the keys came from a key generation ceremony on 30 April 2025 using FIPS 140-2 Level 3 hardware security modules. A wrap and unwrap step in that ceremony produced a second set of weak keys alongside the strong ones, and because the labels looked alike, the weak keys were used for the certificate signing requests. eMudhra says it is still establishing the root cause and re-checking its other ceremonies.

eMudhra also says:

• Its root CA private keys and other intermediates are not affected.
• Only one of the eight intermediates was in production, and none issued end-entity certificates.
• It has stopped issuing under the G3 ECC root and is moving subscribers to its G1 RSA chain. On Bugzilla it estimated about 30,000 certificates need migration, mostly issued through ACME.
• Global TLS is about 1% of its revenue.
• Its Indian Digital Signature Certificate (DSC) and eSign services run on separate infrastructure and are unaffected.

CERT-In's advisory, CIAD-2026-0050, repeats that the domestic DSC and eSign services, regulated by the Controller of Certifying Authorities, are not affected. Some headlines summarised it as a warning about fake websites. That is a warning about what forged certificates could enable, such as impersonation of banking or payment sites, not a report of confirmed fake sites.

CERT-In's recommendations are practical. Users should update browsers and never click through certificate warnings. Administrators should confirm that affected chains are rejected, find services chaining to the affected intermediates or the G3 ECC root, replace certificates, watch CT logs for their domains, and check runtimes, container images, appliances and embedded devices that carry their own CA bundles. For background on CERT-In's role, see our guide to CERT-In directives.

Who is affected

Site owners are affected differently. Google advises anyone holding a certificate that chains to the G3 ECC root to get a replacement from another hierarchy before Chrome's root removal on 27 October.

Why non-browser software is where the risk sits

Browsers recovered fast because they get pushed revocation updates (CRLSet, OneCRL) and enforce CT. Most other software has neither.

Helme lists curl, Python, Node, Go, Java, git and package managers as typical clients that trust a CA bundle on disk and do not check revocation or CT by default. In his tests, a forged certificate for a well-known API domain, served from a local machine, was accepted by default curl, Python and Node on every Linux and macOS system he tried. Revocation by eMudhra changes nothing for those clients. Only a new bundle or a new runtime does.

Cloudflare's post adds three points worth taping to the wall:

1. Your SDK probably does not verify certificates itself. It hands that to an HTTP library, a language runtime, the operating system or a custom trust file, so an SDK update alone may change nothing.
2. Patched packages can be indirect dependencies. Check the whole tree, rebuild images, then restart or redeploy.
3. A browser test proves nothing about a background service, and a curl test proves nothing about an application that uses a different verifier.

Some places to look:

• Container images. The bundle is frozen at build time. A host update does nothing for a running image. See our notes on container image supply chain incidents.
• Language CA bundles. certifi, webpki-roots, Composer's ca-bundle and castore are dependencies pinned in lockfiles. They only move when you move them.
• Java cacerts. Each JDK or JRE carries its own keystore, often several per host.
• Go binaries. The fix lives in the standard library, so it takes a rebuild with a fixed toolchain, not a package update.
• Mutual TLS. If a service accepts client certificates from any public CA, a forged client certificate could pass. LWN notes one affected intermediate carried the client authentication usage. Cloudflare tells mTLS users to review the CAs they trust.
• Devices. Routers, printers and appliances update when their vendor ships firmware, if ever.

What to do now

1. Check your OS trust bundle for the G3 ECC root. Fixed bundles drop it or block the intermediates. Use your distro's bundle path.

# Debian/Ubuntu/Alpine bundle; on RHEL use /etc/pki/tls/certs/ca-bundle.crt; macOS /etc/ssl/cert.pem
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"
dpkg -l ca-certificates    # Debian/Ubuntu
rpm -q ca-certificates     # Fedora/RHEL family
apk info -v ca-certificates  # Alpine

Other emSign roots, such as G1, are not part of the current removal, so match the G3 ECC name exactly. Compare package versions with the tracking site's table.

2. Test the real client against the public test hosts. The tracking site run by Mozilla's Dennis Jackson hosts test endpoints served by the compromised chain. A certificate error is the result you want.

curl https://dv-g3b-emudhra.we-have-a-problem.com/
curl https://dv-g3b-aaa-emudhra.we-have-a-problem.com/
python3 -c "import requests; requests.get('https://dv-g3b-emudhra.we-have-a-problem.com/')"

Where you can, repeat the request through each application's own HTTP client.

3. Check language bundles and runtimes.

pip show certifi                       # want 2026.10.19 or later
grep -c "emSign ECC Root CA - G3" "$(python3 -m certifi)"
keytool -list -cacerts -storepass changeit | grep -i emsign   # each JDK on the host
go version -m ./your-binary | head -1  # built with go1.27.3 or go1.26.10 or later?
node -v

4. Rebuild and redeploy images. Pull fresh base images so the updated ca-certificates package lands, then roll the new images out.

docker build --pull --no-cache -t your-app:fixed .
docker run --rm your-app:fixed sh -c 'dpkg -l ca-certificates 2>/dev/null || apk info -v ca-certificates'
docker run --rm your-app:fixed curl -sS https://dv-g3b-emudhra.we-have-a-problem.com/   # expect an error

5. Find out what your own services present. If you bought certificates from eMudhra, check whether they chain to the G3 ECC root and replace them before 27 October.

openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null 2>/dev/null | grep -E " s:| i:"

6. Review mTLS trust. List the CA files your servers use to verify client certificates. Replace public bundles with your private CA.

7. Never clear errors by turning verification off. Cloudflare calls it "important to not resolve these errors by disabling verification." If a legitimate partner breaks, it needs a new certificate.

What would have helped

Practices any team can use

Treat trust stores as dependencies. A CA bundle is code you ship. Keep an inventory of every place one lives: OS packages in each image, certifi and its peers in lockfiles, each JDK's cacerts, the Go toolchain version behind each binary. Then measure how long it takes to move all of them after an upstream change.

Make updates boring and fast. Automated dependency PRs for bundle packages, scheduled image rebuilds even when your code has not changed, and a quick redeploy path for trust store bumps.

Prefer clients that can receive revocation. Cloudflare says it backs projects such as upki, which treat a trust store as something updated quickly with revocation and CT data, not a static list. Where that is not possible, keep bundles current.

Keep mTLS trust narrow. Client authentication should trust your own CA, not the whole public web PKI.

Monitor CT for your domains. CERT-In recommends it. Helme's point stands that CT "detects mis-issuance though, it doesn't prevent it," so it complements trust updates rather than replacing them.

Key ceremony controls for anyone running a CA, including internal PKI. CERT-In's list is a good template: approved random number generators, proper HSM controls, independent checks of generated key parameters, key identifiers and CSR mappings, and maker and checker sign-off. A simple automated sanity check on every new public key, run by someone other than the ceremony team, catches a whole class of generation bugs. More on this in certificate authority compromise risks and what a certificate authority does.

Where Safeguard fits

Safeguard helps with the inventory and update half of this incident. It does not help with the CA half.

• Finding every bundle you ship. SBOM and dependency scanning covers repos, container images and SBOM files: safeguard scan --dir ., safeguard scan --image <name> or safeguard scan --sbom <file>, with JSON results under ./output. The platform shows which projects contain a given component and version, so "which images still carry the old ca-certificates package" or "which services pin certifi below 2026.10.19" becomes a query rather than a week of grep. Our post on SBOM incident response walks through that workflow.
• Matching advisories. Vulnerability matching against vulnerability databases picks up issues that have published identifiers. A bundle change with no advisory will not show as a vulnerability, so use the component and version view for those.
• Keeping old versions out. Policies and gates evaluated in the platform can be used to hold back builds that still carry an outdated bundle version.
• Making the change. Autonomous remediation can open fix PRs for dependency bumps; it ships off by default. The Safeguard CLI assistant can edit a Dockerfile or lockfile and run the rebuild with your approval of each command, and safeguard exec runs a single non-interactive assistant turn, which suits CI.

Where it does not help: Safeguard cannot see or improve a CA's key ceremony or HSM process, cannot tell you whether a forged certificate was ever used against you, and does not replace CT monitoring. It also will not reach trust stores on hosts, appliances or IoT firmware that you never scan. And no scanner would have prevented this incident; the keys were weak at the source.

Common mistakes

• Calling it a breach. It was a key generation defect. Getting this right matters for how you brief leadership and customers.
• Testing in a browser and stopping there. Browsers were fixed first. Your API clients were not.
• Updating the host and forgetting the images. Containers keep the bundle they were built with.
• Forgetting Go binaries. They need a rebuild with a fixed toolchain.
• Removing roots without checking dependents. Mozilla warned that removing roots cuts off legitimate certificates too, so find your eMudhra-issued certificates first.
• Disabling verification to clear errors. That turns a contained problem into an open one.

FAQ

Was eMudhra hacked?

No breach has been reported. eMudhra says there was no unauthorised access and no customer data breach. The problem is that eight keys were generated weakly in April 2025, so anyone could compute them from public certificates. That is why they were treated as compromised and revoked.

Did anyone forge certificates with these keys?

No abuse has been reported. Google found no TLS certificates from the six web intermediates in CT before its block, and Cloudflare and CERT-In report no confirmed exploitation. Clients that never check CT cannot rule it out, which is why updates matter.

Are Indian DSC and eSign certificates affected?

According to eMudhra and CERT-In, no. Those services run on separate infrastructure regulated by the Controller of Certifying Authorities. The affected intermediates belong to eMudhra's Global TLS business.

Why do some reports say six intermediates and others eight?

Eight intermediates had weak keys: six for TLS and two for code signing. Browser statements focus on the six TLS ones, because web browsers do not trust the code-signing pair for websites.

My website uses an eMudhra certificate. What should I do?

Check whether it chains to the G3 ECC root. If it does, Google advises installing a certificate from another hierarchy before Chrome removes that root, expected on 27 October. eMudhra says it is helping subscribers migrate.

If I only use browsers, am I safe?

Keep them updated and you are covered for browsing. Chrome, Firefox, Android, Apple and Microsoft have all shipped blocks. The work is in servers, scripts, CI jobs, containers and devices.

Try it yourself

Watch the Safeguard CLI handle a dependency fix end to end, asking before each command it runs.

Click through it at your own pace, or open it full screen.

See how to set up the local runner on your own machine and scan from the terminal.

Click through it at your own pace, or open it full screen.

To find every image and service that still ships an old CA bundle, download Safeguard and follow the CLI docs. For the wider month, see October 2026 security incidents and what would have helped.

Quick check

Sources

• Cloudflare: eMudhra certificate compromise
• Google: Protecting Chrome and Android users from compromised eMudhra intermediate CA certificates
• Mozilla Security Blog: Protecting Firefox users following the compromise of eMudhra intermediate certificates
• Mozilla Bugzilla 2083449: eMudhra private key compromise of intermediate certificates
• eMudhra incident tracking and test site
• CERT-In advisory CIAD-2026-0050
• Scott Helme: Eight Bits of Trust
• The Register: eMudhra private keys compromised, one was the number 4
• BleepingComputer: Mozilla, Google, Apple block compromised eMudhra CA certificates
• The Hacker News: Eight eMudhra CA keys compromised
• LWN: eMudhra intermediate CA compromise
• PSU Watch: eMudhra reports key compromise; CERT-In warns of fake websites

Last reviewed: 21 October 2026. This is a developing story; check the linked advisories for the latest status.