Eight certificate keys could be guessed in 256 tries

At 16:27 UTC on Saturday, 17 October, someone who signs himself Wayne ran a test over the public list of certificate authorities and found what he called "a break in the EC keys". Ninety-eight minutes later he emailed Apple, Google, Microsoft, Mozilla and the certificate authority, eMudhra, with proof that he held the private keys of eight of its intermediate certificates.

The heart of Mozilla's write-up is one sentence. A P-384 private key is meant to be a randomly chosen whole number "between 1 and the group order", which is astronomically large. "The 8 impacted keys all used integers less than 256."

So the keys that vouch for websites, six of them trusted by every major browser and two trusted by Microsoft for signing software, could be found by trying 256 numbers. Mozilla found them on its own in under two hours, and says local AI agents managed it on the first try when asked to treat it as a puzzle.

How it happened isn't known yet. What I want to know is simpler: once a key like this is out, who is still exposed?

The short answer

Browsers moved fast. Firefox had blocked the certificates by 22:59 UTC the same evening. Chrome's revocation list carried the six TLS keys by 22:46 UTC. Apple followed on 19 October and Microsoft on 20 October, according to the disclosure page. eMudhra marked the eight as revoked on the morning of 18 October.

And browsers had a second layer. The disclosure page says no Certificate Transparency log entries exist for these intermediates, so browsers that require those logs "could not have been attacked".

The people still exposed are the ones nobody can reach quickly. Mozilla said it plainly in the bug: "many endpoints do not have effective mechanisms for getting revocation information." That's the long tail of software that trusts the same roots but never downloads a revocation list: apps with their own TLS stacks, devices, scripts, back-office systems.

My first reaction, and the check

My first reaction was that this is a scary headline with little real damage, because the browsers fixed it within hours and the logs show nothing was issued.

That's true for browsers. It isn't the whole picture. The flaw had been there since the keys were made on 30 April 2025, about eighteen months. The disclosure page says it doesn't know whether non-browser clients were targeted. And the fix didn't land everywhere at once: Sectigo had cross-signed the same keys, and those copies were still unrevoked while Mozilla's bug was being written up. Sectigo said its root for them had already left the Chrome and Mozilla stores but was still trusted by Microsoft and Apple.

So "fixed" depends on whose client you mean.

The cross: the master key you can file from a door key

In 2003 Matt Blaze, then at AT&T Labs, published a paper about master-keyed locks, the kind in offices and university buildings where your key opens your door and a master key opens all of them. He showed that anyone with an ordinary key and its lock, a few blanks and a file could work out the master key one pin at a time. The lock itself answered yes or no. It worked on every system he tried, usually within minutes.

His conclusion on recovery is the part that maps here. Once the master is out, every lock in the building may need rekeying, new keys have to be handed out, and the old locks stay open to the copied master until someone gets to them. In his words: "Compromise of the master key compromises the entire system."

A certificate authority's intermediate is a master key for the web. Revocation is the rekeying. Browsers are the doors that get rekeyed first, because someone walks round them every day. The rest of the building is everything else that trusts the same root and has never been told the master changed.

What I'd check this week

If I ran anything that makes TLS connections outside a browser, I'd ask two things. Does it trust a system root store, and does it check revocation at all? If the answer to the second is "no" or "don't know", the eMudhra keys are still a working master for that system until the root store update reaches it.

It's the second time this month I've written about randomness nobody checked. NIST's curve seeds turned out to be timestamps. Here the key wasn't even pretending.

How sure am I?

Sources

• Mozilla Bugzilla, Bug 2083449, "Private key compromise of eMudhra Intermediate Certificates" (bugzilla.mozilla.org)
• Disclosure page, "We have a problem" (emudhra.we-have-a-problem.com)
• Matt Blaze, "Cryptology and Physical Security: Rights Amplification in Master-Keyed Mechanical Locks", IEEE Security and Privacy, 2003 (www.mattblaze.org)