Elliptic-curve cryptography rests on one assumption: the private key is a huge random number. For the P-384 curve, security researcher Scott Helme notes, that means one choice out of roughly 10¹¹⁵. Nobody brute-forces that.
One of eMudhra’s private keys was 4. Others were 56 and 115, and researchers have since turned up 66, 155, 156, 230 and 237. Helme says he recovered them from the public certificates on his laptop in less than a second.
What actually broke
On October 17, Mozilla got a community report that private keys behind eight eMudhra intermediate certificates were compromised. Mozilla’s Dennis Jackson laid out the risk plainly: whoever holds those keys can issue fraudulent HTTPS certificates for sites they don’t control. Cloudflare went further and said an attacker could forge a certificate for any domain and use it to intercept or modify traffic.
Mozilla, Chrome and Apple have pushed fixes so their browsers stop trusting the certificates, once users update. eMudhra has revoked them, and a list of open-source projects have shipped updates to reject them. That covers the people with good update hygiene. Internal services, embedded systems and anything else that quietly trusts eMudhra chains are a different problem, and their operators now have to go looking.
The excuse is worse than the error
eMudhra’s statement says the keys came from a Key Generation Ceremony on April 30, 2025, using FIPS 140-2 Level 3 hardware security modules. A flaw in a wrap/unwrap step, it says, produced a second set of weak keys next to the strong ones, and the weak set is what got published to browser root stores. The root cause is still under investigation.
I’ll grant that a botched key-wrapping step is a believable kind of mistake. HSM tooling is fiddly, and ceremonies involve scripts and people. What I won’t grant is the next paragraph, where eMudhra notes these roots and issuing CAs passed independent audits two years running and have sat in browser trust lists since mid-2025.
That isn’t mitigation. It’s an admission that eMudhra’s own checks and its auditors’ checks both missed something any outsider could find from the public half of the key. Helme didn’t need access to an HSM, a ceremony log, or eMudhra’s staff. He needed the certificates everyone already had. A CA whose process lets a single-digit key reach production for over a year has a process problem, and an audit regime that signs off on that twice has one too. Pointing at the auditors doesn’t shrink eMudhra’s share of the blame. It adds a second failure to the pile.
The statement also mentions that TLS accounts for about one percent of eMudhra’s revenue. Investors may find that soothing. For anyone now auditing their infrastructure for eMudhra-signed certificates, it reads as a company explaining why this doesn’t matter much to it.
Distrust is the right call
The browser vendors moved fast and they were correct to. A certificate authority’s whole product is the claim that its keys are secret and unguessable. eMudhra failed at the one thing it sells, and its response so far is a mystery bug, a reference to audits that missed it, and a line about “reputational risks” it says it cannot quantify.
I’d go further than the browsers have. Root programs should treat this as a reason to require automated key-sanity testing of every CA certificate on submission, not just a paper audit of the ceremony. If a researcher’s laptop catches it in under a second, the root store can too.
eMudhra says it is working with affected customers on replacement certificates. It still hasn’t said how a FIPS-certified HSM ceremony produced a private key of 4.