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 G3 hierarchy. The TLS intermediates were issued by emSign Root TLS CA G3, which browsers trusted through a cross-certificate from its publicly trusted ECC root, the emSign ECC Root CA G3. The code-signing pair was issued by emSign Root CS 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 only as Wayne and by Google as "a security researcher," 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, and the others are 56, 66, 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.

The eight certificates and their keys, in detail

These keys are already public, and Chrome, Firefox, Android, Apple and Microsoft all distrust the certificates that hold them. We list the values so administrators can block and detect them in their own systems. They are of no use against a client that has been updated.

Every certificate value below comes from the data files on the tracking site run by Mozilla's Dennis Jackson (impacted-intermediates.json, roots.json and chains.zip). The serials and fingerprints match those listed in Mozilla Bugzilla 2083449, and the crt.sh entry for EM DV TLS CA - G3B shows the same serial, dates and hashes. We also recomputed each certificate hash and public key hash from the PEM files on the tracking site, and all of them matched.

Each of the eight keys sits in two certificates: one issued by eMudhra and one cross-certificate issued by Sectigo's AAA Certificate Services. Both copies hold the same public key, so they share one SPKI hash (the SHA-256 of the public key). That is why Google's CRLSet block matches on the public key rather than on a single certificate.

The eMudhra-issued certificates

All eight use an ECDSA key on the P-384 curve (secp384r1), are signed with ecdsa-with-SHA384, are CA certificates limited to issuing end-entity certificates, and were revoked by eMudhra with reason caCompromise on 18 October 2026 between 09:24 and 09:38 UTC. The G3B certificates name eMudhra BV in the Netherlands as the subject organisation; the G3C certificates name eMudhra Inc in the United States. The six TLS intermediates carry both the TLS server and TLS client authentication usages. Times are UTC.

Serials are written as the tracking site and Bugzilla give them. crt.sh shows the same numbers with a leading 00 byte, which is how the certificate encodes a positive serial.

How the issuing roots fit, according to the tracking site's roots.json and chain files:

• emSign Root TLS CA - G3 (SHA-256 7DD78D5F4F13459A83DFF9ABBBA62EDBAF6F2D102BF257FD712F4D9F2746ED8D) and emSign Root CS CA - G3 (SHA-256 F2EDAAFF3D9B701FB4D14C9F285F8C0BAD90FC3BCC1FA07D47F4718EDABA34A5) are listed as included in Microsoft's root store only.
• Other platforms reached the TLS intermediates through a cross-certificate that makes emSign Root TLS CA - G3 a child of emSign ECC Root CA - G3. That cross-certificate has SHA-256 3094025792039A68AF6E553686410BDAB7C0D4A36B9084CBA64202E35D6EBBDD and is valid from 11 July 2024 to 9 July 2039. The test host chains on the tracking site use exactly this path.
• emSign ECC Root CA - G3 itself has SHA-256 86A1ECBA089C4A8D3BBE2734C612BA341D813E043CF9E8A862CD5C57A36BBE6B. This is the root Mozilla dropped in NSS 3.131.1 and Chrome removes on 27 October.
• AAA Certificate Services (SHA-256 D7A7A0FB5D7E2731D771E9484EBCDEF71D5F0C3E0A2948782BC83EE0EA699EF4, valid to 31 December 2028) is shown as still included by Apple and Microsoft and already removed by Chrome and Mozilla.

The Sectigo cross-certificates

These hold the same eight keys, so the SPKI hashes are the ones in the table above. All eight were signed by AAA Certificate Services with sha256WithRSAEncryption, are valid from 14 May 2025 00:00:00 to 31 December 2028 23:59:59 UTC, and show as revoked with reason caCompromise on 19 October 2026 at 10:35:36 UTC in the tracking site's data. Bugzilla records Sectigo reporting the revocations complete around 20 October.

The private keys as published by researchers

Scott Helme's post maps each recovered private value to its certificate. Each value is the whole private key for both copies of that certificate.

Credit is reported differently by source. The Register says Helme recovered 4, 56 and 115 and that other researchers, not named, reported 66, 155, 156, 230 and 237; it does not map them to certificates. Helme's own post lists all eight with the mapping above. Mozilla says it recovered the keys independently on 17 October, and its bug report describes all eight as P-384 values below 256 without publishing them. The tracking site does not publish the values either. Its proof.zip holds the reporter's proof instead: a short message signed with each of the eight keys, which anyone can check against the public keys.

Why a P-384 key that equals a small number is broken

The public key in each certificate is a point on the curve. It is made by taking the curve's fixed, published base point and multiplying it by the private number. With a proper key, that number is chosen at random from a range about 384 bits wide, so there is nothing to search.

Here the private number was below 256. So anyone could take the base point, multiply it by 1, 2, 3 and onward up to 255, and compare each result with the public key printed in the certificate. One of them matches, and that number is the private key. That is at most 255 cheap calculations, which is why Helme reports recovering all eight in under a second. P-384 itself is not weakened. The curve only protects a key that was chosen from its full range.

How to use these values

• Block by SPKI where your tools allow it. One SPKI hash covers both the eMudhra copy and the Sectigo copy of a key. Chrome's CRLSet already blocks this way, and Firefox, Apple, Android and Microsoft have shipped their own blocks.
• Update trust stores rather than hand-editing them where you can. OpenSSL-based clients (curl, Python, Node, many appliances) and Java trust whatever is in their bundle or keystore. Update ca-certificates, certifi or the JDK, then confirm that emSign ECC Root CA - G3, emSign Root TLS CA - G3 and emSign Root CS CA - G3 are absent. In a Java keystore you can remove a leftover entry with keytool -delete and its alias.
• Windows machines that miss Microsoft's updates. The tracking site offers Block-EmudhraCompromisedCA.ps1, which imports all 16 certificates into the LocalMachine Disallowed store. It covers Windows TLS and Authenticode checks, not applications with their own bundles, and the site asks users of managed devices to talk to IT first.
• Search your inventories. Look for the 16 certificate hashes and 8 SPKI hashes in TLS scan results, certificate inventories, load balancer and proxy configs, stored chain files and container images. Any hit is a chain to replace.
• Search CT. crt.sh accepts a certificate SHA-256 as a search term, as in the crt.sh entry for EM DV TLS CA G3B. Watch CT for your own domains too, as CERT-In recommends.
• Alert on any chain containing them. Network sensors, TLS inspection proxies and SIEM rules that log certificate fingerprints can raise an alert whenever one of these hashes appears. For signed software, flag any binary whose signer chain includes either code-signing intermediate.

To compare a certificate you hold against the tables:

openssl x509 -in cert.pem -noout -fingerprint -sha256
openssl x509 -in cert.pem -noout -pubkey | openssl pkey -pubin -outform DER | openssl dgst -sha256

The first command prints the certificate hash with colons; remove them before comparing. The second prints the SPKI hash in lowercase.

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 noted the client authentication usage on an affected intermediate; the certificates published on the tracking site show all six TLS intermediates, and their cross-certificates, carry it. 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. Count certificates instead of keys and you get 16, because each key also sits in a Sectigo cross-certificate.

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.

Fix it without waiting for upstream

In incidents like this one, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

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
• Tracking site data: impacted-intermediates.json (all 16 certificates with serials, dates and hashes)
• Tracking site data: roots.json (issuing roots and root store status)
• Tracking site data: chains.zip (chains served by the test hosts)
• crt.sh entry for EM DV TLS CA G3B

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