A Trusted Security Company's Secret Key Was the Number 4

What happened

For about a year and a half, one of the keys behind the padlock in your browser was the number 4. Not a hundred-digit number. Just 4.

A certificate authority is a passport office for websites. Its private key is the stamp. Big offices delegate to branch offices, called intermediates, and eMudhra had eight branch stamps at issue here. A proper P-384 key is a random number about 115 digits long. These eight were 4, 56, 66, 115, 155, 156, 230 and 237. Scott Helme recovered them on a laptop in under a second.

A lot of headlines called this a leak. By everything published so far, it wasn’t a break-in. The keys were simply weak enough to calculate. Nobody can prove no one did the maths before October.

On 17 October 2026, at 16:27 UTC, a researcher who signs as “Wayne” flagged the keys while scanning the public CCADB certificate corpus. Less than two hours later he emailed Google, Mozilla, Apple, Microsoft and eMudhra, with a message signed by each key as proof. Chrome blocked the keys an hour and forty minutes after that email. Firefox followed the same night. eMudhra revoked all eight, Sectigo revoked its cross-certificates, and Mozilla removed the parent root. On 22 October eMudhra’s board decided to exit the global SSL/TLS certificate business.

The impact, as far as it is verified: eight intermediates (six for websites, two for code signing), each with a Sectigo twin, so sixteen certificates sharing eight keys. eMudhra says only one was live and it issued no customer certificates. Google found no website certificates from these keys in Certificate Transparency before the block. Cloudflare found no exploitation on its services.

Where the control failed

By my count there were five places this could have been caught. None of them did.

The key ceremony. On 30 April 2025 eMudhra created a batch of new keys. Here is their explanation, and it is theirs; the final root cause is not published yet. The hardware made strong keys. Then an “approved deviation” added a wrap/unwrap test because the keys were meant for export. A flaw in that step created a second, weak set. Because the labels looked similar, the weak keys were used by mistake. eMudhra’s own words: “human errors in multiple steps”.

The cross-signer. About two weeks later, Sectigo cross-signed the same requests. Same weak keys.

The warning sign. This is the part that stopped me. In June 2025, the revocation lists for these same TLS intermediates failed to verify. It was logged publicly and closed in July as a key configuration error. eMudhra now says those lists were first signed with the strong keys, which didn’t match the certificates, so they were re-signed with the weak ones. The system was saying: the stamp you’re using doesn’t match the stamp on file. And the fix was to use the other stamp. Chrome has asked why that link wasn’t disclosed in 2025. As of 22 October, that question is still open.

The audit. BDO’s WebTrust report covered June 2025 to May 2026. All eight intermediates were in scope, and CA key generation is one of the criteria. The opinion was unqualified. The June problem is listed as an “Other Matter”, and it didn’t change the opinion. To be fair, reasonable assurance is not a guarantee, and the report itself says controls may not prevent or detect human error. The April 2025 ceremony sits in the previous audit period, and I couldn’t access that report, so I won’t guess what it says.

The rules. The Baseline Requirements make a CA reject a customer’s key that matches known weak patterns. I couldn’t find an equivalent mandatory test for the CA’s own keys. For a CA’s own intermediates, having an auditor witness the ceremony, or recording it on video, is a “should”, not a “shall”.

Five chances, zero catches. The evidence and the explanation didn’t match in June 2025, and the explanation won.

The evidence an auditor should ask for

If I were auditing a CA, or any team that generates keys, this is what I would want to see. Opinion, not rulebook:

1. Change records for the ceremony script. Any deviation is a change. Show me the independent review and the dry run before it touched production keys.
2. Key-to-certificate reconciliation. Before signing, a second person or a tool matches the public key in each request to the key ID logged when the strong key was created. Similar labels are exactly why maker-checker exists.
3. Weak-key screening results. Every new public key tested against known weak patterns, including tiny private values. Helme’s check took under a second, so cost is no excuse.
4. Root cause that tests the evidence. A revocation list that fails to verify means the signing key and the certificate key differ. Ask which key signed it, and why it doesn’t match. That question in June 2025 might have surfaced this sixteen months earlier.
5. Re-performance, not only inspection. An auditor can compare published certificates against ceremony records and run the same weak-key test, rather than relying on management’s explanation.

CERT-In’s advisory of 21 October says the same thing in plainer terms: CAs should add independent verification and maker-checker controls to key generation. When the national cyber agency recommends maker-checker, that’s an audit control in plain sight.

On India: digital signatures and eSign run on a separate chain rooted in the Controller of Certifying Authorities. eMudhra says they are not affected, and CERT-In repeats that, citing reports. The separate chains are visible in public documents; that the systems and people behind them are also separate comes from eMudhra. As of 22 October, the CCA itself had made no public statement. Meanwhile eMudhra told the exchanges the affected business was about 1% of revenue, and the share price fell about 36% in two sessions. When your product is trust, a failure anywhere gets priced as a question about everywhere.

The test to run this week

Browsers have an emergency channel to push a block like this. Most other software doesn’t. Helme forged a certificate for Stripe’s API address under one of these keys on his own test machine, and with default settings curl, Python and Node accepted it. Cloudflare’s advice: a browser test does not prove a backend service is safe.

So the test for your own organisation is not about eMudhra. It’s about trust you don’t control:

1. List every app, container, script, payment terminal and device that carries its own certificate list.
2. For each one, name who updates it when a certificate authority is distrusted, and how fast.
3. Test through the application’s real connection, not just a browser.

Here is the rule I’d take into your next audit. When the evidence and the explanation don’t match, re-perform the evidence instead of auditing the story.