A Trusted Certificate Authority’s Private Key Was the Number 4

How a small script bug put eight trusted certificates in the hands of anyone who could count to 256, and why your browser was fine but your build pipeline may not have been.

There's an old XKCD joke about a function that returns "4, chosen by fair dice roll, guaranteed to be random." It's funny because nobody would ship that.

In October 2026, a certificate authority more or less did. One of the private keys behind eMudhra's trusted certificates turned out to be the number 4.

This article explains what happened in plain language, why it stayed hidden for about 17 months, and what you should check now. It's written for developers and curious readers, and no cryptography background is needed.

First, a quick refresher: who do you trust online?

When your browser opens a secure site, it doesn't know the server personally. It trusts a chain:

1. Root CA: an organization your operating system or browser already trusts.
2. Intermediate CA: a certificate the root signs, which does the day-to-day work of issuing certificates.
3. Website certificate: the one the site presents to you.

The intermediate CA's private key is the secret that lets it sign new certificates. Whoever holds that key can create a certificate for any website, and the rest of the chain will accept it. That is why Mozilla's engineers said an attacker with the key of any compromised intermediate could impersonate any website or service.

What was found

On October 17, 2026, a researcher known as Wayne reported to the browser vendors that the private keys of eight eMudhra intermediate certificates were compromised. Anyone could recover the keys from the public certificates in under a second.

To prove it, the researcher used each key to sign the same short message: "We have a problem here."

The keys were not 2,048-bit monsters. The eight values were 4, 56, 66, 115, 155, 156, 230 and 237.

Six of the certificates were for TLS (websites) and two were for code signing. The six TLS intermediates chain to the emSign Root TLS CA — G3.

Why a key of "4" is such a disaster

These certificates used elliptic-curve cryptography (the P-384 curve). Here is the simplified version:

• The private key is a secret number, called d.
• The public key is d multiplied by a fixed starting point on the curve, called G.
• Going forward (from d to the public key) is easy. Going backward is considered impossible if d is a truly random 384-bit number, because there are roughly 1⁰¹¹⁵ possibilities.

But the compromised keys were 47 bytes of zeros followed by a single byte. One byte has only 256 possible values. To crack it, you compute 1×G, 2×G, 3×G, and so on until the result matches the public key in the certificate. A laptop does that in a blink, and the keys fell instantly.

The unsettling part is that nothing looked wrong. A key of 4 still produces a perfectly valid point on the curve and passes every structural check. Cryptography can't tell you that your randomness was missing. It will happily work with a "random" number that isn't random at all.

How did a CA end up with a key of 4?

According to eMudhra's explanation on Mozilla's bug tracker, the problem started in a key ceremony on April 30, 2025. A key wrap/unwrap step in the procedure produced a second, weak set of keys alongside the original strong ones. Two key pairs with similar names then existed on the same hardware, and the weak one was mistakenly used to create the certificate requests.

Two things I want to be careful about. First, this is eMudhra's own account and the investigation was still ongoing when I wrote this, so details may change. Second, eMudhra says its root CA keys and other intermediates were not affected.

The warning sign that was missed

The most uncomfortable part of the story is the timeline. According to the incident discussion, in June 2025 another CA noticed that eMudhra's revocation lists carried invalid signatures. The likely reason: they had been signed with the original strong keys, which didn't match the weak keys inside the certificates.

The right response would have been to ask why the keys didn't match. Instead, the lists were reportedly re-signed with the weak keys, which made the error disappear without explaining it. That is a mismatch that should have been treated as an emergency. I'd call it a lesson in process rather than only in mathematics.

Is your browser safe?

Mostly, yes, and the reason is a good one.

• Mozilla blocked the certificates through its OneCRL system on October 17, protecting Firefox users without a browser update or restart.
• Chrome and Firefox blocked them within hours, and Apple and Microsoft followed within days.
• No certificates from these intermediates reportedly appeared in Certificate Transparency (CT) logs. Chrome, Firefox and Safari require TLS certificates to be logged, so a forged certificate that isn't logged gets rejected.

If you're a normal user browsing in an up-to-date browser, you were well protected.

The part that should worry developers

Browsers are the careful ones. A lot of other software isn't.

Tools like curl, Python, Node.js, Go and git generally trust whatever CA bundle sits on disk. They typically don't check CT logs, and often don't check revocation either. Security researcher Scott Helme reportedly forged a certificate for a major API domain, and curl, Python and Node accepted it on the Linux and macOS machines he tested.

So think about where non-browser trust matters:

• Installer scripts that run curl ... | bash
• CI/CD runners holding cloud credentials
• Server-to-server API calls
• Container images built months ago with an old CA bundle
• Devices that rarely or never update, such as smart TVs and routers

An attacker still needs a position to intercept traffic (for example, a hostile network or a compromised router). But in those positions, a forged-yet-"valid" certificate would have been believed.

That asymmetry is my main takeaway. We tend to say "TLS is secure," but what we really have is TLS plus a stack of extra checks that live mostly in browsers. Outside the browser, you're often trusting the CA list alone.

The response so far

• Go shipped emergency toolchain updates that block these eight intermediates in its standard library.
• Cloudflare shipped client updates and, per its statement, found no sign of exploitation on its services.
• Mozilla and Chrome moved to remove eMudhra's root. Check the current status on Mozilla's bug tracker and the Chrome Root Program announcements, because it was still moving when I wrote this.
• eMudhra is issuing replacement certificates to affected customers and cooperating with root programs.
• Some commenters compared the case to DigiNotar, the Dutch CA that collapsed after its 2011 breach. That's an opinion, not a conclusion, but it shows how seriously people take it.

What to do right now

You don't need to panic, but a short checklist is worth ten minutes:

1. Update your CA certificate packages on servers, laptops and CI runners (for example, ca-certificates on Linux).
2. Update language-level bundles. If you use Python's certifi, upgrade to the latest release. If you use Go, update to the patched toolchain release.
3. Rebuild container images. Old images keep old trust stores. This is the step people forget.
4. Test your client. Researchers published test sites that present certificates chaining to the compromised intermediates. Find the current list in Mozilla's incident timeline, then run curl against one. If you get a certificate error, your client is correctly rejecting it. If it connects without complaint, your trust store needs updating.
5. Check IoT and embedded devices. If a device can't be updated, its trust in these certificates could last until they expire (reported as July 2039), so isolating it on the network is worth considering.

Also, if you're an eMudhra customer, ask them directly about your certificates and the replacement process.

What this teaches us

The headline is funny. The lessons are serious.

Randomness failures are silent. Cryptographic systems don't complain about a weak key. Only process can catch it, such as verifying that the key in a certificate is the one you meant to generate.

Ceremonies need verification, not just procedure. Key ceremonies are carefully scripted. This case shows that a script change made to test something can quietly create a second, weaker key pair, and similarly named keys make human mistakes easy.

Mismatches are never "just noise." When two things that should agree (a signature and a key) don't, find out why before making the error go away.

Defense in depth works. Certificate Transparency saved browsers here. The tools without it were the ones left exposed. If you build software that makes TLS connections, consider what extra checks, such as pinning for critical internal calls, make sense for you.

Trust stores are supply-chain infrastructure. We patch libraries religiously. The CA bundle in your container deserves the same attention.

Final thought

The "dice roll" joke works because we assume nobody would ever release something so obviously broken. This incident is a reminder that the failures that hurt most are rarely dramatic. They are small mismatches, ignored warnings and assumptions that "it passed the checks."

Update your trust stores, rebuild your images and run the test. It takes ten minutes, and it closes a door that stayed open for 17 months.

If you patched something because of this incident, I'd love to hear what you found in the comments.