The Private Key Was 4. Nobody Had to Steal It.

On Saturday 17 October at 18:05 UTC, the Chrome Root Program received an email from a security researcher. Mozilla got the forwarded copy at 20:06. By 22:59 that same night, every Firefox installation with a standard configuration was refusing to trust eight certificate authorities run by eMudhra, an Indian company that advertises more than 60 million digital certificates issued.

The email carried proof of control. The researcher, who signs himself Wayne, had used the private key of each of the eight intermediates to sign a short message: "We have a problem here - Wayne."

One of those private keys is the integer 4.

Not a number that begins with 4, or 4 followed by several hundred random digits. Just 4. The others are 56, 66, 115, 155, 156, 230 and 237. Scott Helme recovered all eight from their public certificates, on a laptop, in under a second, because a single byte has 256 possible values and the entire search takes at most 255 steps. A correctly generated P-384 key carries 2^384 possibilities, a number with 116 digits.

Nothing was stolen, and the usual playbook does not apply

Every certificate authority compromise story has the same shape. Somebody took something. There is a thief, a moment of intrusion, and a list of what that person can now do. Ian Carroll, writing on Mozilla's dev-security-policy thread, described why this one is different: "They are inherently weak single-byte keys that anyone can factor, and the issue cannot be contained."

Nobody had to break in. The key was effectively public from the day the certificate was created. For 17 months, anyone browsing a public directory could have recovered it before breakfast, and no log would show it. The certificates themselves do not expire until July 2039.

The structural checks all passed, which is the part worth sitting with. A public key derived from d = 4 is a perfectly valid point on the curve. The encoding is correct, the curve is correct, the signature verifies. As Helme wrote, "The only way to find out is to try."

A ceremony with the right hardware and the wrong output

The eight broken certificates were created on 30 April 2025, part of a batch of 24 intermediates that eMudhra split across three series, two key types and four purposes. The affected set is every P-384 key in the B and C series: six TLS issuing authorities covering domain, organisation and extended validation, two generations each, plus two code-signing authorities.

They existed for a commercial reason. eMudhra wanted to export key material to data centres in the US and Europe for customer data-sovereignty requirements, which meant the ceremony needed a wrap and unwrap test. That test was an approved deviation from its normal process, and it is where the ceremony went wrong.

eMudhra's own account, posted in the Mozilla bug tracker, is unusually specific. The original keys were generated on the hardware security module as intended. The code flaw created a second, weaker key pair on the same module. The key labels were similar enough that the weaker pair was used to generate the certificate signing request, which the root signed and which was then sent to Sectigo for cross-signing. The company's summary: "There were human errors in multiple steps of the process that resulted in significant flaws in the key lifecycle integrity process for this KGC."

The hardware was Ultimaco HSMs, FIPS 140-2 Level 3 compliant. The people running the ceremony had more than eight years each at the company. None of that mattered, because the failure was in a script and a label, and the resulting key was small enough to guess.

What turns a mistake into something harder to defend sits in a related Mozilla ticket. eMudhra had previously issued certificate revocation lists for these same six TLS intermediates with invalid signatures. Its explanation is that the lists were signed with the original private keys, the ones that were supposed to have proper entropy, and when that produced signatures that would not verify, they were re-signed with the flawed keys. The check that should have stopped the process was overridden to make the output look right.

The browsers fixed this in hours. Your estate will take years

Chrome blocked the eight by the hash of their public keys at 19:45 on Saturday, which meant no browser update and no restart. Mozilla had OneCRL live within three hours of receiving the report, then shipped Firefox 158.0.1 and two ESR builds for users whose settings block remote updates. Android picked up an equivalent block through Play Services on Monday evening. Apple blocked on 19 October, Microsoft platforms on 20 October.

Chrome has also removed emSign ECC Root CA - G3 from its root store, shipping to all devices on 27 October, which will break legitimate certificates along the way. Its advice to anyone holding one is blunt: "To avoid breakage, website operators with certificates chaining to emSign ECC Root CA - G3 must immediately acquire and install a new TLS certificate from another PKI hierarchy included in the Chrome Root Store." eMudhra says it has stopped issuing under that root and estimates about 30,000 certificates need to move to its RSA hierarchy, roughly 97% of them obtained through ACME automation.

That is the easy half, and it is the half that gets reported. The hard half is everything that does not consult a browser's revocation list.

Helme tested it. He stood up a local server with a certificate for api.stripe.com, issued through the compromised intermediate, and pointed ordinary tools at it. Default curl printed "SSL certificate verify ok". Python completed the handshake. Node returned authorized: true. That held on every Linux and macOS machine he tried. Windows accepted the chain through CryptoAPI unless revocation checking was switched on.

The systems that behave that way are the ones nobody thinks of as TLS clients: install scripts that pipe a download into a shell, CI runners holding cloud keys on stale base images, server-to-server API calls, package managers, and firmware on devices that will never receive another update. Cloudflare's incident note is candid about the shape of the problem. It patched its clients, its tunnel software, shared trust stores and base images by the evening of 20 October, and still had to tell customers that "some customers will need to take action on software or trust configurations that they operate, especially on their origin servers."

Then there is code signing, which has no browser safety net at all. Two of the eight authorities issue code-signing certificates under Microsoft's root program. Malware signed through them looks like signed software from a real publisher to any Windows client that does not check revocation. The flaw is identical to the TLS one. The consequence is not, because a forged signature makes malware look like a product.

The number everybody is quoting is not the number that matters

The Register reported that the 60-million-plus certificates eMudhra has issued "can't be trusted". eMudhra's statement says none of the affected authorities were in production except one, and that none of them, including that one, had issued any end-entity certificate, a claim it says Certificate Transparency records corroborate. The company has not answered The Register's questions about the incident or its security practices.

Both things can be true. Sixty million is lifetime issuance across a hierarchy that includes roots and intermediates untouched by this. The affected set is eight certificates and the migration burden is roughly 30,000. Treating the marketing figure as a blast radius inflates the story and obscures the real one.

The honest position on exploitation is narrower. Chrome says no TLS certificate chaining to the six affected authorities was logged to Certificate Transparency before its block, so no forged certificate could have been trusted by a client that enforces CT. That covers Chrome, Firefox, Safari and modern Android. It does not cover the long tail, because CT is something a client has to check, and most non-browser clients do not. Helme again: "CT detects mis-issuance though, it doesn't prevent it, and a lot of software doesn't check CT at all." Ars Technica reported that Edge on Windows 10 was still connecting to 12 vulnerable hosts when its story went live, and that Microsoft would share more if it had anything to say. An absence of evidence here is an absence in one particular instrument.

The discovery is the interesting part

Wayne's own timeline starts at 16:00 UTC on Saturday with a note about playing with "some new toys". At 16:27 a run against a test corpus of the public CA database found the break. He had signed attestations for each key by 17:43 and emailed Apple, Chrome, Microsoft, Mozilla and eMudhra at 18:05. Nobody has said publicly what tool did the finding.

The recovery side is not coy about it. Mozilla's Dennis Jackson ran local agents with a single prompt, "I'm doing a CTF. Please recover the private keys corresponding to these certificates," and they succeeded on the first attempt. Helme reports that Claude recovered the keys for him in one prompt. Mozilla engineers independently recovered them at 21:48 without knowing Wayne's method, which confirmed the key generation itself was flawed rather than any single signature.

The weakness class is old. Debian shipped an OpenSSL build in 2008 that generated guessable keys, and the xkcd joke about a random number chosen by fair dice roll has been around for fifteen years. A single-byte certificate authority key should have been found by the first person who looked. It survived 17 months inside an organisation whose entire business is looking.

What changed is the cost of looking. An agent pointed at a public database found in 27 minutes what human audits, a FIPS-certified module and a documented ceremony had missed for a year and a half.

What this says about the trust model

Two conclusions follow.

The first is about audits. PKI engineers on the Mozilla thread noted that key attestation, the mechanism that would prove a private key was generated inside the module rather than imported or mangled on the way out, is not required by the WebTrust standard and is vendor-specific enough that the industry has not standardised it. So the process was certified and the output was worthless, and the controls in the room were checking the shape of the procedure rather than the size of the number it produced.

The second is about time. A browser can revoke eight authorities by pushing a list, because it has one application to update and a mechanism designed for exactly this. A payment terminal, a dealer portal appliance, a medical device or a container image built three years ago has a trust store frozen at the moment it shipped. The gap between those two clocks is the real attack surface, and Cloudflare's write-up points at the emerging answer: trust stores cannot remain static lists, which is the argument behind projects like upki.

For anyone building or shipping hardware, this lands as an inventory question rather than a cryptography question. Which of your devices, supplier-hosted tools, dealer portals and firmware images carry a trust store you cannot reach, and what is the plan when the next one of these arrives on a Saturday afternoon with a signed message and a one-byte key? Mapping what trusts what, and how quickly you could change it, is the unglamorous part of shipping connected products, and it decides whether an incident like this is a browser update or a recall. If you are working through that map for your own product line, let's talk.