The Private Key That Was Just “4”: What the eMudhra Incident Teaches Us About Trust on the Internet

A certificate authority trusted by Chrome, Safari, Firefox and Windows shipped eight signing keys that anyone could guess in under a second. Here is what happened, why it mattered, and what you should check in your own stack today.

On the evening of 17 October 2026, a security researcher who goes by "Wayne" sent an email to Google, Mozilla, Apple, Microsoft and an Indian company called eMudhra. Attached was a message, "We have a problem here," signed with eight private keys that should have been among the best-guarded secrets on the internet.

They belonged to eight intermediate certificate authorities run by eMudhra, a publicly listed company whose certificates were trusted by every major browser and operating system. One of those keys was the number 4. Another was 56. None was larger than 255.

Within two hours Chrome had blocked them. Within five days eMudhra's stock had hit its lower circuit twice and the company had walked away from the global SSL/TLS business entirely.

The incident looks complicated. It isn't. Once you understand how the padlock in your browser works, the whole failure fits in one sentence. So let's start there.

Part 1: How a website gets its padlock

Say you're launching example.com, an e-commerce site. Security comes first, which means HTTPS, which means you need a TLS certificate. Every site on the internet gets one the same way.

Step 1: Generate a key pair. On your server you create a public key, which you can show to the world, and a private key, which never leaves your control.

Step 2: Create a CSR. A Certificate Signing Request bundles your domain name and your public key, signed with your private key. Think of it as an application form: "I am example.com, and this is my public key."

Step 3: A Certificate Authority (CA) signs it. You send the CSR to a CA such as Let's Encrypt, Google Trust Services, DigiCert or, until last month, eMudhra. The CA checks that you really control the domain, then signs your certificate with its own private key.

Step 4: The browser verifies it. Your server presents the certificate. The browser checks the CA's signature, and if everything is valid you get the padlock.

Click the padlock on any site and you'll see it: "Verified by Google Trust Services", the validity dates, the public key. All of it is public, and that's fine, because a public key is meant to be public.

The whole system depends on one assumption: only the CA can produce the CA's signature. Keep that in mind.

Part 2: The chain of trust

How does your browser know which CAs to trust? It doesn't trust websites. It trusts a short list of root certificates that ship offline with the browser or operating system, roughly 150 of them.

A useful way to think about a root is as a friend you trust blindly. If that friend vouches for someone, you trust them too.

In practice there are three layers:

• Root CA. Built into Chrome, Firefox, macOS, Windows, Android. Valid for 20 to 25 years. Kept offline and used rarely, because getting a new root onto every device in the world takes years.
• Intermediate CA. Signed by the root. Does the daily work of signing website certificates. Valid for about 5 to 10 years.
• Website (leaf) certificate. Signed by an intermediate. Valid for months, not years.

When you visit yourbank.com, the server sends its own certificate and the intermediate. The browser walks the signatures upward. If the chain ends at a root it already holds, the connection is trusted.

The consequence is easy to miss: an intermediate CA's private key carries the full authority of the root above it. Whoever holds it can produce a certificate for any domain on the internet, and every device that trusts the root will accept it.

Every program also brings its own list of roots. macOS has one. Chrome has its own. Firefox has its own. Node.js ships a copy of Mozilla's list, Python's certifi ships another, and your smart TV has whatever was flashed into it at the factory. Remember this too. It decides who was still exposed after the browsers were fixed.

Part 3: What went wrong at eMudhra

eMudhra's root, emSign ECC Root CA — G3, was trusted by Chrome, Apple, Microsoft and Mozilla. Underneath it sat eight intermediates in the "G3B" and "G3C" series:

• Six for websites: EM DV, OV and EV TLS CA — G3B and G3C
• Two for code signing: EM OV CS CA — G3B and G3C

They used ECDSA on the P-384 curve. A properly generated private key for that curve is a random number about 116 digits long, chosen from roughly 1⁰¹¹⁵ possibilities. The public key reveals nothing practical about it. Recovering one by brute force would take far longer than the age of the universe. That one-way property is the entire point.

eMudhra's eight keys looked like this:

Mozilla described them as effectively all zeros apart from the last byte. A single byte holds only 256 possible values. To recover any of these keys you take the public certificate, try 0, 1, 2 … up to 255, and stop when one produces the matching public key. It takes under a second on a laptop.

It's worth being precise about what this was not. Nobody stole these keys. eMudhra's infrastructure wasn't hacked and no data was breached. The keys were broken from the moment they were created, and the public half of each one, sitting in every certificate chain, was enough to work out the private half.

Part 4: How does a CA end up with a key of "4"?

CA keys are created in a key ceremony: a scripted, audited, often video-recorded process in which keys are generated inside a Hardware Security Module (HSM), a tamper-resistant device built so that private keys never exist in readable form outside it.

According to eMudhra's own incident report on Mozilla's bug tracker, this is what happened at its ceremony on 30 April 2025:

1. Twenty-four intermediates were created in one session. The ceremony included an approved deviation: a test of key wrap/unwrap for export.
2. The script for that test had a flaw. Alongside each strong, HSM-generated key, it created a second, weak key pair. eMudhra later confirmed the weak keys were generated outside the HSM.
3. The two sets had similar labels. For eight of the 24 intermediates, the weak key was the one used to build the CSR.
4. eMudhra's root signed those CSRs, and Sectigo cross-signed them, which extended their trust to older devices that only know Sectigo's legacy "AAA Certificate Services" root.

eMudhra acknowledged human error at several steps of the process.

The detail that hurts most is that there was a warning sign. In May 2025, CRLs (certificate revocation lists) for six of the TLS intermediates were published with invalid signatures. That is the kind of anomaly that should stop everything. Instead, the CRLs were re-signed with the weak keys and the question of why the signatures were wrong was never answered. The broken keys then sat inside trusted chains for about 17 months.

Part 5: What an attacker could do

With an intermediate's private key in hand, the playbook is short:

1. Take eMudhra's public intermediate certificate.
2. Try keys 0 to 255 until one matches.
3. Sign a certificate for yourbank.com, netflix.com, or anything else.

Then put yourself on the victim's network path: a hostile café Wi-Fi, a compromised router, a malicious ISP hop. When the victim's device requests the real site, you serve your own server with a certificate that validates all the way up to a trusted root. The padlock shows. "Connection is secure."

This matters most for the sites people don't already know. You might notice netfIix.com with a capital "I", but for a random PDF tool, a game download or a small fintech app, the padlock is the only trust signal most people check. With a stolen intermediate key, the padlock says nothing.

The two code-signing intermediates were their own problem. They were trusted by Microsoft, so an attacker could have signed malware that Windows would present as coming from a legitimate publisher.

Why browsers were (mostly) fine

The modern Web PKI has two safety nets, and both worked:

• Certificate Transparency (CT). Chrome, Safari and Firefox reject TLS certificates that haven't been logged in public, append-only CT logs. The Chrome Root Program said no TLS certificate chaining to the six intermediates had been logged before the block, so no forged certificate from them could have been trusted by default in a CT-enforcing browser.
• Remote kill switches. Chrome's CRLSet and Firefox's OneCRL let vendors distrust a certificate across all installs remotely, without a restart. Chrome blocked the intermediates 1 hour 40 minutes after the report. Firefox's block reached users in under three hours.

eMudhra has said it found no evidence the keys were used maliciously before disclosure. Whether anyone quietly found them during those 17 months is unknowable.

Part 6: The ten days that followed

The containment was a model of how the ecosystem should respond. eMudhra revoked all eight intermediates on 18 October with the reason CA compromise. Sectigo revoked its cross-signs. Apple and Microsoft shipped blocks. Mozilla removed emSign ECC Root CA — G3 from NSS on 20 October, and Chrome followed on 27 October.

The business fallout was brutal. eMudhra's shares hit their 20% lower circuit on 21 October (₹540 → ₹432) and again the next session. On 22 October the board announced a voluntary exit from the global SSL/TLS certificate business, which the chairman said made up about 1% of revenue. The company stressed that its Indian Digital Signature Certificate and eSign businesses run on separate infrastructure and were not affected.

eMudhra was one of very few Indian companies with a root certificate in the world's major trust stores. That's a hard position to earn, and it was lost in about a week.

Part 7: Who is still exposed?

For most people on an updated laptop or phone, the honest answer to "what should I do?" is: nothing, it's already handled. You don't control what your browser trusts, and the browser vendors acted within hours.

Developers and ops teams are a different story, because every program that verifies TLS carries its own trust store, and each one had to be fixed separately.

Checklist for your stack:

• Linux servers and containers. Update ca-certificates. Running containers keep their old bundle, so rebuild with a fresh base: docker build --pull --no-cache.
• Python. Upgrade certifi to 2026.10.19 or later. Update pip and uv, which vendor their own.
• Node.js and Electron. Node ships a copy of Mozilla's roots. Updating Firefox does nothing for your Node service. Upgrade the runtime.
• Go. Roots and checks compile into the binary. Rebuild with a patched Go release.
• Rust and Java. Update webpki-roots / rustls-webpki. Check your JDK's cacerts.
• macOS command-line tools. curl and friends read /etc/ssl/cert.pem, which doesn't get the same remote blocking as Safari.
• Windows. Make sure automatic root updates aren't disabled by Group Policy. Look for binaries signed by the two compromised code-signing CAs.
• IoT, smart TVs and appliances. This is the long tail. Many have frozen trust stores, never update, and may still trust Sectigo's old AAA root (which expires at the end of 2028). Ask your vendors for patches.

Test it yourself. The researcher runs test hosts signed by the compromised keys:

curl https://dv-g3b-emudhra.we-have-a-problem.com/

curl https://dv-g3b-emudhra.we-have-a-problem.com/

A certificate error is the result you want. If the connection succeeds, that client still trusts the compromised keys. And whatever you do, don't "fix" an error here by turning off certificate verification.

If you hold certificates from eMudhra's G3 hierarchy, migrate to another CA. eMudhra estimated that around 30,000 certificates were affected.

Part 8: Lessons for anyone who builds things

1. Your security is only as strong as your weakest generated secret. P-384 is solid. The HSM was fine. The cryptography never failed; the process around it did. One script, one confusing label and one unchecked step undid all of it.

2. Verify your output, not just your procedure. A one-line check, "is this private key suspiciously small?" or "does this public key match the one the HSM reports?", would have caught this before a single CSR was signed. Ceremonies are audited for following the steps. They also need to check what the steps produced.

3. Anomalies are signals, not chores. Invalid CRL signatures in May 2025 were the system telling eMudhra something was wrong. Re-signing made the symptom go away and left the cause in place. Every on-call engineer has done a version of this, and this is what it can cost at internet scale.

4. Trust stores are dependencies. Treat them like dependencies. Most of us track our npm and pip versions closely and have no idea which root list our production containers carry. After this incident, that's worth knowing.

5. Defense in depth works. CT logging and remote revocation exist because the industry assumed a CA would eventually fail. When one did, those layers meant browser users were effectively never exposed. If you're designing a system that relies on trust, build the kill switch and the audit log before you need them.

The one-sentence summary

The internet trusts browsers, browsers trust roots, roots trust intermediates, and for 17 months eight of eMudhra's intermediates were protected by a number you could guess on your fingers.

Check your containers, update your runtimes, and run that curl.

Sources: Mozilla Bugzilla #2083449; Google Chrome Root Program statement; Cloudflare, Keytos, Aikido, Kudelski Security, Unit 42 and Endor Labs analyses; The Hacker News, BleepingComputer, Help Net Security and ThePrint reporting; NSE market data via Ventura Securities and Angel One. Diagrams by the author.

If this helped you understand the incident, give it a clap and share it with your team's ops channel. Somebody there is running an old container.