Skip to content
Cyber Security

October 21, 2026

eMudhra CA Compromise: Eight Intermediate Keys Were Guessable

Probir Sarkar
6 minute read

Eight eMudhra intermediate CA private keys — one literally the number 4 — could be recovered in seconds from public certificates. Browsers blocked them within days; servers and bundled trust stores still need updates.

eMudhra CA Compromise: Eight Keys Were Guessable — BrowserStay blog

On October 17, 2026, a researcher going by Wayne reported that the private keys of eight intermediate certificate authorities operated by Indian trust provider eMudhra had been compromised — not stolen, but recoverable by anyone from the public certificates alone. The P-384 keys, generated in April 2025, had values smaller than 256. One was literally the number 4. Security researcher Scott Helme recovered all eight in under a second; Mozilla's engineers independently reproduced the recovery the same day, confirming the key-generation process was flawed.

An attacker holding any of those private keys could forge certificates for any website and intercept encrypted traffic in a man-in-the-middle position. Six of the intermediates were for TLS, chaining to roots trusted by the Mozilla, Microsoft, Apple, and Chrome root programs; the other two were for code signing.

eMudhra logo
Image: eMudhra logo via Wikimedia Commons (public domain)

The response, hour by hour

The disclosure moved fast. Mozilla received the report on October 17 and blocked the certificates in Firefox within about three hours; Chrome blocked them the same day through a CRLSet update. Apple followed on October 19, Microsoft on October 20. eMudhra revoked the compromised intermediates on October 18, with Sectigo revoking related cross-signs on October 19. The issue carries the identifier CVE-2026-111943.

The fallout goes beyond the eight keys. Mozilla and Chrome are also removing trust in the root those intermediates chain to, emSign ECC Root CA - G3 — a step that breaks every certificate issued under that root, including ones unrelated to the compromise. eMudhra estimates about 30,000 certificates need migrating, the vast majority issued through ACME, and says it is moving subscribers to its RSA root. India's CERT-In issued its own advisory, noting the keys could be used to build fraudulent sites impersonating payment entities.

Why browsers are safe and servers may not be

If you browse with an updated Firefox, Chrome, Safari, Edge, or Android device, you are protected — the blocks are already in place, and Google reports no certificates chaining to the compromised intermediates ever appeared in Certificate Transparency logs.

The risk sits with everything that keeps its own list of trusted certificates: servers, containers, language runtimes, and command-line tools. Node.js, Go, rustls-webpki, Electron, Python's certifi, Perl's Mozilla::CA, curl bundles, and Linux distribution ca-certificates packages have all shipped updates; Debian's update also cuts the Sectigo cross-sign path. Red Hat published an expedited bulletin for RHEL's system trust store. Until those updates land, systems can still trust forged certificates.

To test a command-line client, run:

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

A certificate error means the client no longer trusts the compromised intermediates — that is the result you want. (A page saying the connection succeeded means you are still vulnerable.)

How to check your own systems

Start with what you browse with: make sure Firefox, Chrome, Safari, or Edge is updated — the blocks shipped days ago through normal update channels, including Google Play Services for Android. Then move to the less visible users of trust stores. On servers, update the OS CA bundle (ca-certificates on Debian/RHEL families, plus Red Hat's expedited bulletin) and restart TLS-terminating services so they pick up the new bundle. For language runtimes and tools, update Python's certifi, Node.js, Go, and any vendored curl bundle; the curl project publishes its own updated bundle, and the absence of the emSign root in it is the signal you are current. Container images deserve a rebuild, not just a host patch — a base image pinned from before October 20 carries the old trust store inside it. If your organization issues internal tooling with a pinned CA bundle, reissue it from the updated upstream.

eMudhra is leaving the TLS business

On October 22, eMudhra's board decided to withdraw from the global SSL/TLS certificate business entirely. Chairman V. Srinivasan cited rising compliance and data-sovereignty costs, cost-free certificates from larger rivals, and a segment worth about 1% of global revenue — then added the line that reads as the real reason: “the level of social media amplification around this incident has brought scrutiny that is out of proportion to SSL/TLS's place in our business.” The decision was filed with the stock exchanges and repeated in a company press release; Ars Technica, The Hindu BusinessLine and Zee Business all reported it.

What that changes for anyone holding an eMudhra-issued certificate, per the company's own statement: its G1 RSA roots stay in service until the transition completes, certificates are to be replaced free of charge through partner CAs, and revocation and certificate-status services keep running until every issued certificate has expired or been replaced. eMudhra also still owes the browser root programs a full root-cause report. Its signing, eSign, PKI-platform, eSigner and authentication businesses run on separate infrastructure and are unaffected.

The calendar is unchanged. Chrome removes emSign ECC Root CA - G3 from the Chrome Root Store on October 27, 2026, Pacific time, and has warned that legitimate certificates chaining to that root will break with it. Mozilla has already removed the root from NSS, and in the same round removed two more eMudhra roots — emSign Root CA - C1 and emSign ECC Root CA - C3 — at eMudhra's own request, since neither is part of the company's future hierarchy. Chrome says it is still weighing whether G1 should stay in its store, a question the exit makes academic for new issuance but not for the certificates already in use.

What is still open

There is still no evidence of issued rogue certificates or in-the-wild exploitation — and Mozilla's advisories note that the absence of logged certificates does not rule out unlogged ones, since not all clients enforce Certificate Transparency. The dated risks are the ones that matter now: the October 27 removal breaks any certificate still chaining to the distrusted root, the migration of roughly 30,000 certificates now runs alongside the company's exit from the business, and downstream trust stores — Amazon Linux, Red Hat, Bottlerocket and Corretto among them — were still catching up as of October 22. Watch for breakage reports once Chrome's change reaches stable, and for the root-cause report eMudhra has promised the root programs.

Last updated October 23, 2026, adding eMudhra's decision to exit the global SSL/TLS business. We will revise this post as the migration completes.

emSign logo
Image: emSign logo via Wikimedia Commons (public domain)

No comments yet