eMudhra's certificate authority keys were tiny integers, crackable from public certs in milliseconds

Eight intermediate certificate authorities operated by eMudhra rested on private keys that were trivially small integers — one of them literally the number 4 — and security researcher Scott Helme reports he recovered all eight from their public certificates in under a second on an ordinary laptop. Browser vendors have blocked the certificates, but the blast radius extends well beyond the browser.

What happened

According to Helme, a security researcher privately notified Apple, Google, Microsoft, Mozilla and eMudhra on Saturday 17 October that the private keys for eight eMudhra intermediate certificates were compromised. Chrome shipped a CRLSet update blocking them that evening, and Mozilla blocked them in Firefox via OneCRL a few hours later. On Tuesday 20 October Mozilla disclosed the issue publicly and shipped an NSS update removing the eMudhra root, and Chrome confirmed the root will be dropped in Chrome Root Store v43.

The eight intermediates are six TLS issuing CAs — domain-validated, organisation-validated and extended-validation, in two generations each — plus two code-signing CAs. All were created in April 2025, and every one was also cross-signed by Sectigo's AAA Certificate Services root in May 2025.

One byte of entropy

The keys are elliptic-curve keys on P-384. The private key is a number, d, and the public key published in the certificate is d multiplied by a fixed curve point G. The security model depends entirely on d being a random value close to 384 bits long — roughly 2^384 possibilities, about 10^115 — which nobody can enumerate. As Helme shows, eMudhra's keys instead consist of 47 zero bytes followed by a single meaningful byte. A single byte has only 256 possible values, so breaking the key means computing 1 x G, 2 x G, 3 x G and so on until the result matches the certificate — at most 255 steps.

Helme downloaded the 16 affected certificates Mozilla attached to its announcement (each of the eight keys appears twice, issued once by eMudhra and once through Sectigo) and brute-forced every one instantly. The recovered values include 4 for the OV TLS G3C intermediate, 56 and 115 for the two EV intermediates, and 237 for a code-signing CA. Ian Carroll put it succinctly in the discussion thread: these are single-byte keys that anyone can factor, which makes the problem impossible to contain.

Notably, nothing about the certificates looks wrong. A public key derived from d = 4 is a perfectly valid curve point, and all structural and encoding checks pass. The only way to detect the flaw is to attempt the recovery, which almost nobody does.

Why it cannot be contained

A normal CA key compromise involves theft, and you can at least reason afterwards about who holds the key. Here nothing needed to be stolen: the keys were effectively public from the moment the certificates existed in April 2025, and anyone who looked at one could have recovered it in milliseconds on commodity hardware. Helme stresses there is no way to know whether anyone did.

Chrome noted, as Helme relayed, that it enforces Certificate Transparency and no TLS certificate chaining to these CAs ever appeared in CT logs, so a forged certificate would not have been trusted by default in Chrome. True, he concedes, but CT detects mis-issuance rather than preventing it, and a great deal of software never consults CT at all.

Who is still exposed

Updated mainstream browsers are largely safe: Chrome and Firefox block the intermediates directly and both require CT, and Safari requires CT as well. Nearly everything else is a different story. Most non-browser TLS clients — curl, Python, Node, Go, Java, git, package managers and the scripts and daemons built on them — trust a CA bundle on disk, skip revocation checks by default and ignore CT. The intermediates' revocation by eMudhra and Sectigo therefore does nothing for them.

Helme enumerates the exposed surface: curl-and-pipe installers and self-updaters, where a forged certificate means running attacker code, often as root; CI/CD pipelines holding cloud credentials; server-to-server API traffic (the AWS CLI and boto ship their own trust bundle, while Terraform and kubectl are Go programs); IoT and embedded devices with frozen trust stores; and Windows code signing, since Windows trusts the eMudhra code-signing root directly, letting malware signed with these keys masquerade as software from a real publisher.

He verified the impact by serving a forged certificate for api.stripe.com from a local machine: with default settings curl reported the certificate as verified, Python completed the handshake and Node reported authorization success on every Linux and macOS machine tested. Windows accepted the chain unless revocation checking was enabled — and even then only one of the two possible chain paths came back revoked.

Why it matters

This is not a break in P-384 or in certificate validation; it is a catastrophic failure of key generation, and it was invisible to every conventional check. Entire CA hierarchies — TLS and code signing alike — rested on eight bits of entropy for roughly a year and a half. The episode also lays bare how unevenly PKI protections are distributed: browsers get aggressive blocking, CT enforcement and modern revocation systems, while the vast population of non-browser clients will keep trusting these intermediates until someone updates their trust store, and frozen IoT bundles may never receive that update. Cheap, routine testing for pathologically small keys — simply trying to recover them — would have caught this on day one.