Last Saturday, a researcher who goes by "Wayne" pointed some new key-checking tooling at the public set of CA certificates that browsers trust. According to his own timeline in Mozilla's bug tracker, he started at 16:00 UTC and had a hit by 16:27.
Twenty-seven minutes.
What he found was eight intermediate certificate authorities belonging to eMudhra, the Indian CA behind the emSign brand, whose private keys were whole numbers below 256. A P-384 private key is supposed to be a random number around 115 digits long, so these weren't weak in some subtle, academic way. Mozilla's Dennis Jackson described them as "effectively all-zeroes apart from the last byte." Nobody stole them. If you had the public certificate, and everyone does, you could just work them out.
I've been thinking about this one all week, mostly because of how ordinary the failure was.
Here's the short version of what happened. The keys came out of a key-generation ceremony on 30 April 2025. Six were TLS CAs trusted by Chrome, Firefox, Safari and Windows, and two were code-signing CAs trusted by Microsoft. Sectigo had cross-signed all eight. Hold one of those TLS keys and you can mint a certificate for any domain you like, and a client that trusts the chain will believe you. For a CA, it doesn't get worse than that.
Credit where it's due, the response was fast. Wayne emailed Apple, Google, Microsoft, Mozilla and eMudhra at 18:05 UTC on the 17th. Chrome had the six TLS CAs in a CRLSet push within a few hours, and Mozilla recovered the keys itself without being told how, then finished its OneCRL block at 22:59 UTC. eMudhra revoked all eight the next morning. Sectigo pulled its cross-signs, Apple and Microsoft followed, Google covered Android, and Go shipped patch releases. Firefox put out 158.0.1, then 158.0.2 because some Android profiles weren't picking up the blocklist at startup. Once several people had recovered the keys on their own and a few had posted them, Mozilla removed trust in the whole emSign ECC Root CA G3, and Chrome said it'll do the same. eMudhra puts the migration at roughly 30,000 certificates.
eMudhra's statement says seven of the eight were never in production, the eighth never issued a certificate, its infrastructure wasn't breached, and its Indian DSC and eSign services aren't affected. Fine. I'll take that at face value for now.
So how does a one-byte key get past an HSM?
This is the bit that bugs me.
eMudhra says the keys were generated on FIPS 140-2 Level 3 HSMs, which is exactly the hardware you're supposed to use. There was a formal ceremony. The hierarchy then went through two independent audit cycles. On paper it's all fine.
Per eMudhra's preliminary account in the bug, these keys were headed for data centres in the US and Europe, so an approved deviation added a wrap/unwrap test to the ceremony. A flaw in the ceremony script reportedly created a second set of keys on the HSM alongside the good ones, and those were weak. The two sets had similar labels. The weak ones were reportedly picked by mistake when the CSRs were built, the root signed them, and the same CSRs went to Sectigo. eMudhra says there were "human errors in multiple steps" and admits gaps in its maker/checker controls. Its 21 October update is clear that the exact root cause still isn't confirmed, so keep that in mind.
And then there's the part that honestly made me wince. In mid-2025, CRLs for these same CAs failed signature verification (Bug 1970728). eMudhra says those CRLs had been signed with the original strong keys, which obviously didn't match the public keys in the certificates. The fix was to re-sign them with the weak keys, and the bug was closed. Fenko Security called that "the single loudest signal a PKI can give you." I agree. The system told them the certificate held the wrong key, and they made the error go away.
I think that's the whole story, really. Everyone checked the process. The hardware was certified, the ceremony was scripted, the deviation was approved and the audits were signed off. Nobody checked the output. Was the public key in that CSR derived from a private key that looks random? It's a check that takes seconds and needs no special tooling.
The browsers came out of it fine. No certificate chaining to these CAs ever showed up in Certificate Transparency logs, and Chrome, Safari, Firefox and Edge won't accept a TLS cert that isn't logged, so a forged certificate wouldn't have worked there. Cloudflare says it saw no exploitation on its network either.
What worries me is everything else. The keys were recoverable from April 2025 onward, and a huge amount of software doesn't enforce CT or check revocation at all. That includes Go binaries that only pick up the fix when they're rebuilt, Python apps pinned to an old certifi, Node, Electron, a container image nobody's touched since spring, the TLS-inspection box in the corner of someone's data centre. Mozilla's test site and The Hacker News both make the point that past misuse against clients like those can't be ruled out. eMudhra says it's "not aware of any evidence" of exploitation. That's an honest answer, but it isn't the same as a clean bill of health.
The business side is rough too. The Hacker News, citing Business Standard, reported a 20% drop in eMudhra's share price on 21 October, and Chrome says it's "thoroughly evaluating" the remaining root.
What would have stopped it? Nothing exotic. Test every key as it's generated, before a CSR exists: look for tiny or structured scalars and compare against known-weak lists. Treat ceremony scripts like production code, with version control, review and tests, and run it all again whenever someone signs off a one-off deviation, because that's exactly where this went wrong. Give keys labels a tired person can't mix up, and have a second person confirm the CSR's public key matches the handle they meant to use. When a signature doesn't verify, stop. Don't re-sign until the error goes away. And if you ship software with its own trust store, ask yourself how long it'd take you to pull a CA. Days? Months?
AI cuts both ways here
This is the part I keep coming back to. Mozilla tried a few local AI agents and says they recovered the keys on the first try from a simple prompt along the lines of "I'm doing a CTF. Please recover the private keys…" Wayne used "some new toys," and eMudhra says he reportedly had help from AI-assisted tooling. A few years ago spotting this took a specialist who knew what to look for. Now it's a prompt.
Defenders get the same tools, though, and I think that's the more useful thing to take away. Put a key-quality gate in CI, so any key or CSR coming out of a ceremony pipeline gets checked and a weak one fails the build. Run automated CT monitoring for certificates under CAs you depend on. Have a model read your ceremony scripts and ask the boring question of every line: which key does this actually touch? Have a human read them too. eMudhra now says it'll add "AI based tooling" to its ceremony reviews. Good, but the people running these scans across the whole public corpus aren't waiting for anyone's next audit.
None of this means HSMs or audits don't matter. They do. They just told everyone the process was followed, and that turned out to be a different question from whether the key was any good.
Verify outputs, not just processes.
Educational post based on publicly reported facts. No exploit code. eMudhra's root-cause investigation is ongoing, so details may change.
Sources: Mozilla Bugzilla 2083449 · Google · eMudhra statement · Cloudflare · Fenko Security · Test site · BleepingComputer · The Hacker News · Ars Technica