TL;DR
- eMudhra is an Indian certificate authority that sells TLS and code-signing certificates under the emSign brand, and an intermediate CA is the certificate that signs the certificates individual websites present to a browser.
- A researcher showed the root programs on 17 October 2026 that the private keys of eight eMudhra intermediates were single-byte numbers, one of them literally four, recoverable from the public certificate in under a second on a laptop.
- Chrome blocked the six TLS keys at 19:45 UTC that evening and Mozilla finished its OneCRL block for Firefox at 22:59 UTC; eMudhra revoked all eight intermediates at 09:38 UTC on 18 October.
- Browsers take revocation from a list they fetch themselves, so the block landed with no update and no restart; every other client trusts a CA bundle on disk and can keep trusting a revoked chain for months.
- The trust stores that live in code moved next, with Go 1.27.3 and 1.26.10, NSS 3.131.1, Python certifi 2026.10.19, Rust webpki-roots 1.0.10 and a Homebrew exclusion shipped by 20 October, while a Node.js fix remains pending.
- An administrator can check on Monday morning which bundles each fleet ships, then confirm that a test chain through the emSign root now fails.
- Mozilla removed emSign ECC Root CA - G3 from NSS on 20 October and Chrome will remove it in root store version 43, and Chrome is reviewing eMudhra's other root, emSign Root CA - G1.
Mozilla's incident ticket for the eight eMudhra intermediates (bugzilla.mozilla.org, bug 2083449, captured 2026-10-20), which records the ticket as resolved and carries eMudhra's own account of the key ceremony in its comments.
A private key of four, and sixteen certificates that passed every check
Scott Helme recovered all eight private keys from their public certificates on a laptop, and the whole exercise took less than a second. The values are 156, 230, 155, 4, 115, 56, 66 and 237, one per intermediate. Helme pulled all sixteen certificates behind them, because each key was used in two: one issued by eMudhra and one issued by Sectigo as a cross-sign. The certificate named EM OV TLS CA - G3C carries a private key equal to the number four.
The arithmetic behind that number explains why it fell so quickly. These are elliptic-curve keys on the P-384 curve, where the private key is an integer d and the public key is d × G. A correct P-384 key is a random 384-bit number, one of roughly 10 to the power of 115 candidates. eMudhra's keys are 47 bytes of zeros followed by a single byte, which reduces the search to at most 255 steps: compute 1 × G, 2 × G, 3 × G, stop when the result matches the certificate.
Nothing else about those certificates looks wrong. A public key derived from d = 4 is a perfectly valid point on the curve, the encoding is correct, the curve is correct, and every structural check passes. The only way to find out is to try, which is what happened in October 2026, seventeen months after the material was created in one ceremony on 30 April 2025 and cross-signed by Sectigo's AAA Certificate Services root in May 2025.
Netics editorial diagram built from the key values published by Scott Helme on 2026-10-20: a correct P-384 key sits in a space of about 10 to the power of 115, while these eight keys sit between 0 and 237.
Why revocation reached browsers in hours and everything else in months
The report reached the root programs on the evening of 17 October and the machines responded at the speed of a push channel. Chrome had the report at 18:05 UTC and a CRLSet update blocking the six TLS intermediates at 19:45 UTC. Mozilla had it at 20:06 UTC and finished a OneCRL block for Firefox installations with standard settings at 22:59 UTC. Neither update needed a restart, because CRLSets and OneCRL are lists the browsers fetch on their own.
The certificate authority followed. eMudhra revoked all eight intermediates at 09:38 UTC on 18 October. Apple blocked them on 19 October, Sectigo revoked its cross-signs the same day, and Microsoft followed on 20 October.
Then the browser story ends and the operational one starts. Every non-browser client trusts a CA bundle on disk, skips revocation checks by default and skips Certificate Transparency, a list that covers curl, Python, Node, Go, Java, git, package managers, and the scripts and daemons around them. Revoking a certificate does nothing for a client that never asks whether it was revoked. Helme tested a forged certificate for api.stripe.com against curl, Python and Node with default settings, and all three accepted the chain. That is the gap between an incident a browser closed within hours and one that lasts until an image is rebuilt.
The Mozilla dev-security-policy thread of 20 October 2026 (groups.google.com, captured the same day), where Mozilla's Dennis Jackson published the affected certificate list and the disclosure timeline.
The trust stores that live in code
Go took the most direct route. Releases 1.27.3 and 1.26.10 reject any chain containing one of the eight keys under CVE-2026-111943, the check sits in the standard library and covers Go's own verifier plus the macOS and Windows system-verifier paths, and the change adds no setting to switch it off. A program picks it up when it is rebuilt with the new release.
The other fixes work by taking the root out of the bundle: NSS 3.131.1 drops emSign ECC Root CA - G3, Python certifi 2026.10.19 drops the same root, Rust webpki-roots 1.0.10 drops it, and Homebrew's ca-certificates excludes it along with emSign Root TLS CA - G3 and AAA Certificate Services. Removing a root also cuts off every legitimate certificate that chains through it, and Mozilla said some servers will become unavailable to non-Firefox users of its trust list until those servers move to new certificate chains.
A Node.js fix is still pending, which means a large population of services keeps the old bundle until a base image is rebuilt.
Netics editorial timeline assembled from the root-program reporting of 2026-10-20: Chrome's CRLSet at 19:45 UTC, Mozilla's OneCRL block at 22:59 UTC, eMudhra's revocation at 09:38 UTC on 18 October, and the NSS root removal on 20 October.
What an administrator can check on Monday morning
Start with an inventory. Every container image, every language runtime and every toolchain that ships its own bundle holds a CA list that ages with the image, and a review that covers certificate handling and trust configuration will surface those lists faster than an incident will; that is the ground security audit and hardening covers in practice. The practical questions are concrete: which base images carry the emSign root, which services are built with a Go release older than 1.27.3, and which machines accept a test chain through EM DV TLS CA - G3B right now.
Then there are the devices nobody can update quickly. Routers, printers, televisions, appliances and industrial controllers with frozen firmware will trust these certificates until the intermediates expire in July 2039, and a forged certificate presented to one of them produces the same padlock a user expects. In our reading, Windows code signing carries the same flaw on a different path: software signed with EM OV CS CA - G3B or EM OV CS CA - G3C looks like signed software from a real publisher to anything that skips revocation.
eMudhra's own public site (emudhra.com, captured 2026-10-20), which presents the company as a digital trust provider and lists the emSign product family behind the affected intermediates.
Where eMudhra's trust goes from here
Mozilla removed emSign ECC Root CA - G3 from NSS on 20 October. Chrome will remove the same root in version 43 of its root store and is reviewing eMudhra's other root in that store, emSign Root CA - G1. The Chrome Root Program said it checked every other CA certificate in its store and found no other instance of this failure mode; that check covers Chrome's own store only, and the review of emSign Root CA - G1 is still open.
The root cause is documented, and the accountability question remains open. eMudhra's account inside Mozilla's ticket describes a bug in the ceremony script that created a second weak key pair on the HSM during a key-wrapping test, and labels similar to those of the intended keys, and the weak keys were the ones used for the certificate requests. A warning existed in May 2025, when the CRLs for the six TLS intermediates began failing signature checks and Sectigo filed a bug about it; eMudhra re-signed those CRLs with the keys matching the certificates and closed the incident as a process error.
For the certificate authority, that decision cost sixteen months of trust, counted from the May 2025 CRL warning; the seventeen-month exposure window runs from the creation of the keys in April 2025. For everyone running a fleet, the bill arrives on a schedule set by the oldest base image in the estate, and a printer whose frozen firmware ships the emSign root can still trust this chain in 2039.
Originally published on the Netics blog.
Top comments (0)