The eMudhra Private Key Compromise

The eMudhra Private Key Compromise

If you only have a minute, here’s what happened:

•     What: eMudhra, a Bengaluru-based certificate authority trusted by every major browser, had the private keys of eight of its certificates exposed in October 2026.

•     Why it matters: with those keys, anyone could create a valid-looking certificate for any website, including your bank, your email or a government portal.

•     Google, Mozilla, Apple and Microsoft moved within days to block the certificates, and eMudhra’s shares fell by a fifth in a single day.

•     Browsers are protected now, but many apps, servers and devices may still trust those certificates until someone updates them.

So how does a certificate authority trusted by every major browser, using certified security hardware and passing two audits, end up with keys that anyone could work out? And why did nobody notice for 18 months?

 When I joined my role about a month ago, I thought of certificates as plumbing: the padlock shows up and the connection is secure. The eMudhra incident showed me how much that padlock depends on one thing, a certificate authority keeping its private keys secret.

Here is what I pieced together from the public bug thread, the browser vendors’ posts, eMudhra’s own statement and the news coverage.

How certificate trust works

Browsers trust a small set of root certificate authorities. Roots sign intermediate CAs, and intermediates sign the certificates websites use. Anyone holding an intermediate’s private key can sign a certificate for any domain, and an attacker who can intercept traffic could then impersonate websites.

What was wrong with the keys

eMudhra is a Bengaluru-based CA that claims over 60 million certificates issued. Eight of its intermediates, six for TLS and two for code signing, used P-384 keys. A proper P-384 key is a random 384-bit number with about 10¹¹⁵ possibilities.

Mozilla found that all eight keys were smaller than 256, so anyone could find them by trying 256 values. Scott Helme recovered them in under a second on his laptop. One key was 4, others were 56 and 115. Nobody broke in. The keys were weak from the day they were made.

How it was found

A researcher known only as “Wayne” signed the message “We have a problem here - Wayne” with each key and sent it to the browser root programs on 17 October 2026. Mozilla’s Dennis Jackson later published the proof and a test site at emudhra.we-have-a-problem.com.

What the browsers did

Chrome blocked the keys through a CRLSet update and Firefox through OneCRL, both without users needing to restart. Android got the same block through Google Play Services on 19 October, and Microsoft and Apple followed. Chrome and Firefox are also removing the emSign ECC Root CA - G3, and Google checked every other key in its root store and found none with the same problem. The good news came from Certificate Transparency: Google found no website certificates from these intermediates in public logs, so browser users were never exposed. Apps that don’t check these logs are a different story.

Why other software matters more

Many apps, scripts, containers and devices carry their own list of trusted roots and never check revocation. They keep trusting the bad chain until someone updates them, which is why so many projects shipped fixes (The Hacker News):

Cloudflare added a useful warning: if errors appear after patching, don’t switch off certificate verification to make them go away.

What eMudhra says went wrong

In the bug thread, eMudhra explained that its April 2025 ceremony tested a key export step. A code flaw created a second, weaker key pair in the HSM, and because the labels looked alike, the weak keys were used by mistake. Its statement admits the flaw went unnoticed for about 18 months across two audits, and says none of the eight issued customer certificates. Mozilla is still waiting for answers to 14 follow-up questions.

The impact on eMudhra and India

eMudhra says only one US customer is affected, while the bug thread mentions about 30,000 certificates to migrate. Its shares fell 20% on 21 October and another 16% the next day. CERT-In issued an advisory and MeitY set up a team to investigate, while officials said eMudhra’s Digital Signature and eSign services are unaffected.

What to check

1.    Replace any certificate that chains to emSign ECC Root CA - G3.

2.    Update runtimes and CA bundles, rebuild Go binaries and container images.

3.    Review mutual TLS trust stores and custom CA lists for the eight intermediates.

4.    Test your real application with the test site, not just a browser.

5.    Never disable certificate verification to get rid of errors.

What I took away

What surprised me most is that nothing was hacked. The hardware was certified and the maths was fine, but one step in a ceremony went wrong and two audits missed it. For me, the lesson is to know which trust stores my systems use before an incident forces me to find out.

Sources

•     Mozilla Bugzilla 2083449: the full technical thread, including the key analysis and eMudhra’s root-cause explanation (bugzilla.mozilla.org).

•     Mozilla Security Blog: how Firefox blocked the certificates and which versions to update (blog.mozilla.org).

•     Google Security Blog: Chrome and Android protections, and why CT logs kept browser users safe (blog.google).

•     Cloudflare: what non-browser software and servers should check and fix (blog.cloudflare.com).

•     eMudhra statement: the company’s own account, customer impact and next steps (emudhra.com).

•     Proof and test site: the researcher’s signed proof and a tool to test your own systems (emudhra.we-have-a-problem.com).

•     The Register: how researchers recovered the keys, including the key that was just 4 (theregister.com).

•     The Hacker News: timeline and the list of software fixes and CVEs (thehackernews.com).

•     ThePrint: MeitY’s investigation and the impact on eMudhra’s shares (theprint.in).