eMudhra CA keys were tiny numbers, one was 4: Chrome drops the emSign root on October 27

Eight eMudhra intermediate CA keys could be recovered in milliseconds. Browsers blocked them within hours, Chrome removes emSign ECC Root CA - G3 on Tuesday, October 27, and eMudhra is leaving the global TLS business.

The Proof DeskOct 26, 2026 · 7 min read

The number 4 shown as a P-384 private key beside the emSign ECC Root CA - G3 name and the October 27 Chrome removal date

A certificate authority's private key is supposed to be a random number so large that no computer could ever guess it. Eight of eMudhra's were smaller than 256. One of them was 4.

The keys belong to eight intermediate CA certificates that eMudhra, an Indian certification authority that says it has issued more than 60 million digital certificates, created in April 2025. Anyone who looked closely at the public certificates could have recovered them for about 17 months, until an outside researcher reported the problem on October 17, 2026. Browsers blocked the intermediates within hours and no forged certificates have been found.

What still needs action is a deadline. On Tuesday, October 27 (Pacific time), Chrome removes emSign ECC Root CA - G3 from its root store, and any site whose certificate still chains to that root will show Chrome visitors a full-page security warning.

What happened

On October 17, 2026, an external researcher identified only as Wayne reported that the private keys of eight eMudhra intermediate CA certificates were compromised. The Chrome Root Program forwarded the report to Mozilla, where it is tracked as Bugzilla bug 2083449, "eMudhra: Private key compromise of Intermediate Certificates".

The eight certificates fall into two groups:

Six TLS CAs - EM EV TLS CA, EM OV TLS CA and EM DV TLS CA, each in a G3B and a G3C version - trusted by Chrome, Mozilla, Microsoft and Apple.
Two code-signing CAs - EM OV CS CA - G3B and EM OV CS CA - G3C - trusted by Microsoft only.

All eight were created at a key generation ceremony on April 30, 2025, and the intermediates were cross-signed by Sectigo's AAA Certificate Services root in May 2025. That is the start of a 17-month window in which the keys were effectively public.

Timeline from the April 30, 2025 key ceremony through the October 17, 2026 report, browser blocks, eMudhra's exit and Chrome's October 27 root removal — Key dates in the eMudhra incident. Times are UTC except the Chrome root removal, which is Pacific time.

Why a key of 4 is a catastrophe

These are P-384 ECDSA keys. A P-384 private key should be a random 384-bit number, roughly 10^115 possibilities. Every one of eMudhra's eight keys was below 256: all zeros except the last byte. As a comment on the Mozilla bug puts it: "P384 private keys are randomly selected integers between 1 and the group order. The 8 impacted keys all used integers less than 256...can be recovered near instantly via the baby-step giant-step discrete log algorithm."

Table of the eight compromised eMudhra intermediate CAs and their recovered P-384 private key values, from 4 to 237 — Recovered private key values, as published by Scott Helme. A real P-384 key has 384 bits; these fit in one byte.

The eight recovered values

EM OV TLS CA - G3C: 4
EM EV TLS CA - G3C: 56
EM OV CS CA - G3B: 66
EM EV TLS CA - G3B: 115
EM OV TLS CA - G3B: 155
EM DV TLS CA - G3B: 156
EM DV TLS CA - G3C: 230
EM OV CS CA - G3C: 237

Because each key fits in a single byte, recovering one takes at most about 255 steps. Security researcher Scott Helme recovered all eight in under a second on ordinary hardware.

What the keys allow

Apple's summary: "Someone with keys from these six CAs could create certificates that appear valid for any website." The two code-signing keys could likewise sign software that Windows would accept as coming from a verified publisher.

How it happened, in eMudhra's words

eMudhra traces the failure to an approved deviation from its usual key generation ceremony, made to test key wrap and unwrap. In the Mozilla bug the company wrote that "a flaw in the code resulted in the second pair of keys being created onboard which were weaker...these second pair of weaker keys were used by mistake to create the csr (because the key labels were similar) and signed by our root."

Its public statement is blunt: "The flaw was ours. A script error resulted in issuing CA's with weak keys." eMudhra adds that it is "not aware of any evidence that the weak keys were recovered or exploited by anyone before the issue was disclosed", that "the affected intermediates had not issued publicly trusted end-entity certificates", and that its digital signature, eSign and enterprise services run on separate infrastructure and were not affected.

How browsers and platforms responded

The response was fast. Chrome had the intermediates blocked less than two hours after receiving the report, without a browser update or restart.

Six cards showing when and how Chrome, Firefox, Apple, Microsoft, Android and eMudhra blocked or revoked the compromised intermediates — Each platform's first blocking action. Apple's 12 certificates are the six TLS CAs under two issuers.

October 17, 18:05 UTC - Chrome receives the report.
October 17, 19:45 UTC - Chrome pushes a CRLSet update blocking the SPKI hashes of the affected intermediates.
October 17, 21:48 UTC - Mozilla independently recovers the private keys; OneCRL distrust is complete at 22:59 UTC.
October 18, 09:24-09:38 UTC - eMudhra revokes all eight certificates with reason caCompromise.
October 19 - Apple starts blocking 12 certificates: the six TLS intermediates in two versions each, one under emSign Root TLS CA - G3 and one cross-signed by Sectigo.
October 20 - Microsoft blocks the affected certificates; Firefox 158.0.1 and ESR updates ship with the new blocklist.
October 21, around 22:00 UTC - Android gets equivalent protection through Google Play Services.
October 22 - eMudhra's board decides to exit the global SSL/TLS business.
October 23 - Apple extends its block to emSign ECC Root CA - G3.
October 27 (Pacific time) - Chrome's removal of emSign ECC Root CA - G3 reaches every device that uses the Chrome Root Store.

Apple's 12 certificates are not 12 compromised keys. There are eight keys in total; Apple counts each of the six TLS intermediates twice because each exists under two issuers.

Google says the exposure for Chrome users was limited: "Because no TLS certificates chaining to these six intermediate CAs were logged to Certificate Transparency (CT) before our blocking action, no fraudulent certificates issued by these CAs could have been used against CT-enforcing clients." Cisco Talos said on October 21 that it "has not seen any malicious incidents involving them in the wild yet" and published Snort detection rules (SIDs 67363-67374).

The remaining risk sits outside the browser

Browsers enforce Certificate Transparency and receive push updates to their blocklists. Much of the software that makes TLS connections does neither. Helme forged a certificate for api.stripe.com with one of the recovered keys, and it validated with default settings in curl on Linux and macOS, Python, Node.js and Windows CryptoAPI unless revocation checking was turned on.

Two panels listing the systems still exposed if not updated, such as non-browser TLS clients, CI containers and IoT devices, and the projects that have already updated their trust stores — Browsers are covered. Clients with their own CA bundle need an update or a rebuild.

The places most likely to still trust the compromised intermediates:

Non-browser TLS clients: curl, Python, Node.js, Go, Java, git and package managers.
CI/CD pipelines and build containers built on an older CA bundle.
IoT, embedded and OT devices with frozen firmware. The intermediates do not expire until July 2039.
Windows code-signing verification, which is where the two code-signing CAs matter.
Server-to-server API calls and cloud SDKs.

Fixes are out across the stack. Go shipped 1.27.3 and 1.26.10 for CVE-2026-111943, and NSS, curl, Homebrew, Node.js, Python certifi, Rust's rustls-webpki, Electron, Ubuntu, Debian and Arch Linux have all updated trust stores or blocklists. Apple says a future macOS update will extend its block to command-line tools that read /etc/ssl/cert.pem.

Helme's warning is the reason this does not end with the browser fixes: "They are inherently weak single-byte keys that anyone can factor, and the issue cannot be contained."

What to do before October 27

If you run a website

SSL.com warns that Chrome visitors to sites still on emSign ECC Root CA - G3 "can start seeing a full-page security warning on Tuesday morning, October 27, 2026, Pacific time." Check your chain from a terminal:

openssl s_client -connect yourdomain.com:443 -servername yourdomain.com -showcerts </dev/null | grep -iE "emsign|emudhra"

Run the command above for every public hostname. No output means no emSign or eMudhra certificate in the chain.
If anything matches, get a new TLS certificate from a CA in a different hierarchy that is included in the Chrome Root Store, as Google instructs.
Install it and confirm with the same command before Tuesday morning Pacific time.
eMudhra customers can get replacement certificates at no cost through its partners, including Sectigo certificates on request.

Checklist with the openssl command for checking a certificate chain, four steps for website owners and six steps for servers, CI and devices — The same checks as above, on one page.

If you run servers, pipelines or devices

Update the operating system's ca-certificates package on every host.
Update Python certifi, Node.js, Go (1.27.3 or 1.26.10), curl, Homebrew packages, rustls-webpki and Electron apps.
Rebuild container images instead of trusting the CA bundle baked into an old layer.
Inventory embedded and IoT devices whose trust store only changes with a firmware update.
Turn on revocation checking where your TLS client supports it.
Test a client against the live checker at emudhra.we-have-a-problem.com, the community incident page run by Mozilla's Dennis Jackson, which also hosts messages signed with each of the eight keys as proof of compromise.

eMudhra exits the global TLS business

On October 22, eMudhra's board decided to voluntarily exit the global SSL/TLS certificate business, which the company puts at about 1% of its global revenue. Digital signature certificates, eSign, enterprise PKI (emCA and CertiNext), emSigner, SecurePass/emAS and all India-based operations continue. The G1 RSA roots keep serving customers during the transition, and revocation and status services stay up until every certificate has expired or been replaced. A full root-cause report goes to the browser root programs.

Chairman V. Srinivasan framed it this way: "For many certifying authorities, SSL/TLS is the whole business. For eMudhra it is one part of a much broader digital solutions portfolio."

eMudhra says one customer ecosystem in the US is affected and is receiving replacement certificates from an alternate CA. Enterprise TLS customers are being offered CA redundancy at no cost.

Sources

Google Security Blog: https://blog.google/security/protecting-chrome-and-android-users-from-compromised-emudhra-intermediate-ca-certificates/
Mozilla Bugzilla bug 2083449: https://bugzilla.mozilla.org/show_bug.cgi?id=2083449
Apple Support: https://support.apple.com/en-us/149555
eMudhra incident statement: https://emudhra.com/en/post/certificate-security-incident
eMudhra press release: https://emudhra.com/en/press-release/emudhra-to-exit-global-ssl-tls-certificate-business
Scott Helme: https://scotthelme.co.uk/eight-bits-of-trust-emudhras-ca-keys-cracked-in-milliseconds/
Community incident page and checker: https://emudhra.we-have-a-problem.com/
Cisco Talos: https://blog.talosintelligence.com/compromised-intermediate-certificates/
BleepingComputer: https://www.bleepingcomputer.com/news/security/mozilla-google-apple-block-compromised-emudhra-ca-certificates/
The Register: https://www.theregister.com/security/2026/10/20/indian-certification-authority-emudhras-private-keys-compromised-one-of-them-was-the-number-4/5304312
SSL.com: https://www.ssl.com/article/check-your-certificates-before-october-27-chrome-is-removing-an-emudhra-root/

Key takeaways

Eight eMudhra intermediate CA keys, six TLS and two code-signing, were P-384 keys with values below 256. One was 4.
The keys were recoverable in milliseconds for about 17 months, from April 2025 to October 2026.
Chrome, Firefox, Apple, Microsoft and Android blocked the intermediates between October 17 and 21, and no forged certificates have been found.
Chrome removes emSign ECC Root CA - G3 on Tuesday, October 27, Pacific time. Sites still chaining to it will show a full-page warning.
The biggest remaining risk is non-browser software with stale trust stores: update CA bundles and runtimes, and rebuild containers.
eMudhra is leaving the global SSL/TLS business but keeps its signing, enterprise PKI and India operations.