eMudhra's Cracked CA Keys: What It Means for HTTPS Trust

By Jaspal Singh October 21, 2026 Updated: October 21, 2026

Eight intermediate certificate authority keys belonging to eMudhra, an Indian CA, were generated so badly that anyone could recover them from the public certificates, letting an attacker mint a trusted HTTPS certificate for any website. Browsers blocked them within hours of the 17 October report, but many apps, servers and devices still need updates.

What Happened

On Saturday, 17 October 2026, a security researcher told the browser root programs that the private keys behind eight eMudhra intermediate certificates could be recovered by anyone. According to the Mozilla dev-security-policy thread, Chrome received the report at 18:05 UTC and pushed a CRLSet update blocking the six TLS-issuing intermediates at 19:45 UTC. Mozilla received its report at 20:06 UTC and blocked all eight in Firefox through OneCRL at 22:59 UTC, a mechanism that needs no browser update or restart.

Apple devices began blocking the certificates on 19 October and Microsoft platforms on 20 October, according to the incident page maintained by Mozilla engineer Dennis Jackson. On 20 October Mozilla also shipped an NSS update that removes the root certificate that signed the intermediates, and Chrome said its Root Store version 43 will remove the eMudhra root. eMudhra has revoked the compromised intermediates.

The flaw was not subtle. Security researcher Scott Helme, in his analysis of the eight keys, found that every private key was zero except for its final byte. One intermediate, EM OV TLS CA - G3C, had a private key equal to the number 4. The others were 56, 66, 115, 155, 156, 230 and 237. Helme recovered all of them on a laptop in under a second. The certificates were created in April 2025 and cross-signed by Sectigo's AAA Certificate Services root in May 2025, so the keys were effectively public for about 17 months.

Cloudflare, which says it learned of the problem around 17:00 UTC on 19 October, described it in its incident write-up as a serious security incident with implications across the internet. It shipped updates to its WARP client, the 1.1.1.1 app and cloudflared, and finished deploying mitigations across its CDN and Zero Trust products by 19:20 UTC on 20 October. Cloudflare said it found no active exploitation on its services.

Why It Matters

HTTPS rests on a simple promise: when your browser shows a padlock, a trusted certificate authority has vouched that the server really belongs to the domain in the address bar. Any CA that browsers trust can vouch for any domain. That makes every trusted CA key a master key for the whole web, not only for the CA's own customers.

A recoverable intermediate key breaks that promise completely. Someone holding one could issue a certificate for a bank, an email provider or a software update server, then sit between a victim and the real site, reading or altering traffic while the connection still looks valid. Cloudflare stressed that this is a failure of certificate-based authentication, not of TLS encryption itself. The ciphers were fine; the identity check was what fell over.

The browsers were well protected. Chrome's root program said no TLS certificates chaining to these intermediates had been logged to Certificate Transparency before the block, so a browser that enforces CT would not have accepted a forged certificate by default.

The bigger exposure is everything else. Command-line tools, programming language runtimes, containers, IoT devices and corporate appliances often carry their own bundle of trusted roots, rarely check revocation and do not enforce CT. Helme reported that many non-browser TLS clients still trusted these chains by default when he tested them. That is why Linux distributions, Python's certifi, pip, uv, Go and curl are shipping new certificate bundles this week, and why some, including Node.js and Bun, were still listed as pending on Jackson's tracker at the time of writing.

There is also a cost to legitimate sites. Mozilla warned that removing the root from NSS may make some servers unreachable for non-Firefox users until those sites move to a different certificate chain. Website operators who bought certificates from eMudhra need to check what they serve.

How It Works

The keys were elliptic-curve keys on the P-384 curve. In elliptic-curve cryptography, a private key is just a number, usually written d. The public key is that number multiplied by a fixed starting point on the curve, G. Computing d × G is quick. Working backwards from the result to d is believed to be infeasible, but only because d is chosen at random from a space of roughly 2³⁸⁴ possibilities, a number with about 115 digits.

eMudhra's keys threw that protection away. With only the last byte set, each key had at most 256 possible values. Recovering one takes nothing more than trying 1 × G, 2 × G, 3 × G and so on until the result matches the public key printed in the certificate. Nothing about the public key itself looks wrong: it is still a valid point on the curve, which is why the weakness sat unnoticed in widely trusted certificates for a year and a half.

How did a CA end up using such keys? Helme cites eMudhra's own account on Mozilla's bug tracker: a bug in the key ceremony script created a second, weak key pair on the hardware security module, and because the key names were similar, a person picked the wrong keys when generating the certificate signing requests.

The fix happens in layers. Browsers have fast revocation channels: Chrome's CRLSets and Firefox's OneCRL and CRLite push block lists to clients in hours. Chrome blocked the keys by their SPKI hash, which also covered the Sectigo cross-certificates that share the same keys. Two of the eight intermediates were code-signing CAs, which Chrome did not need to block because it does not accept TLS paths through code-signing-constrained intermediates.

Software outside the browser usually has no such channel. It trusts whatever roots were in its bundle when it was built, so it stays exposed until someone ships a new bundle and every machine, image and container picks it up. Mozilla's advice to trust store operators was to block the specific intermediates if they can, or otherwise remove trust in the affected roots: the Sectigo AAA Certificate Services root and emSign ECC Root CA - G3.

For developers, Cloudflare's guidance is practical. Find out which trust store your code actually uses, whether that is the operating system, the language runtime or a bundled file. Update indirect dependencies and rebuild container images rather than assuming an SDK update fixed things. Test through the application's real TLS path, since a working browser or curl command does not prove a background service is protected. And never switch off certificate verification to make errors go away.

What's Still Unknown

The biggest open question is whether anyone used the keys before 17 October. CT logs show no TLS certificates from these intermediates, which rules out attacks on CT-enforcing browsers, but a forged certificate used against a non-browser client would not have to appear in any log. Jackson's incident page says plainly that it is not known whether attackers exploited the flaw against such clients.

eMudhra's future in browser trust stores is undecided. Chrome said it is evaluating the company's remaining CA certificates against its standards for continued inclusion, and Mozilla has already pulled the root that signed these intermediates. eMudhra says it has issued more than 60 million digital certificates over its history, many of them document-signing certificates in India, so the commercial stakes are high. As of 20 October the company had not answered press questions about its security practices.

Finally, it will take weeks to learn how many legitimate websites and services relied on these chains and broke when the roots were removed, and how many embedded devices will never receive an updated bundle at all.

Frequently Asked Questions

Do I need to do anything as an ordinary internet user?

Update your browser, phone and computer operating system. Chrome and Firefox blocked the certificates on 17 October without needing a restart, Apple began blocking them on 19 October and Microsoft on 20 October. Because these browsers enforce Certificate Transparency and no forged certificates were logged, everyday browsing in a current browser was not shown to be at risk.

What is an intermediate certificate authority?

Root certificates are kept offline and rarely used. Instead, a root signs intermediate certificates, and the intermediates sign the certificates that websites install. Browsers trust a website's certificate if it chains back to a trusted root through valid intermediates. That makes an intermediate key as powerful as the root for issuing website certificates, which is why these eight keys mattered so much.

Why was a private key of 4 so easy to crack?

An elliptic-curve private key is a number that should be chosen at random from about 2 to the power of 384 options. eMudhra's keys used only one byte, so there were at most 256 candidates. An attacker simply multiplies the curve's base point by 1, 2, 3 and onwards until it matches the public key in the certificate, which takes well under a second.

Were any websites actually attacked?

Nobody has reported a confirmed attack. Chrome said no TLS certificates chaining to these intermediates appeared in Certificate Transparency logs before the block, and Cloudflare found no active exploitation on its services. However, an attack against software that does not check those logs would leave no public trace, so exploitation against non-browser clients cannot be ruled out.

Which software still needs to be updated?

Anything that carries its own list of trusted roots: Linux ca-certificates packages, Python's certifi, pip and uv, Go, curl's CA bundle, container base images, Java and Node.js runtimes, and embedded devices. Patched versions have shipped for several, including certifi 2026.10.19 and pip 26.2.2, while Jackson's tracker listed Node.js, Bun and FreeBSD as still pending on 20 October.

How do I know if my own website uses an eMudhra certificate?

Inspect the certificate chain your server sends, using your browser's certificate viewer or an online SSL checker, and look for eMudhra, emSign or an EM DV, OV or EV TLS CA - G3B or G3C intermediate. If you find one, get a replacement certificate from another CA promptly, because clients that removed the roots will now refuse to connect.

Does this break HTTPS encryption?

No. The encryption algorithms used by TLS were not weakened. What failed was the identity check that tells your device it is talking to the real server. A forged certificate lets an attacker pose as that server, so the connection is encrypted but to the wrong party. Revoking and distrusting the keys restores the identity check for updated clients.

Why could Chrome block the keys in under two hours?

Chrome and Firefox maintain their own revocation channels, CRLSets and OneCRL, that push lists of blocked certificates to browsers in the background. Chrome blocked the six TLS intermediates by the hash of their public keys, which also caught Sectigo cross-signed copies. Most other software lacks such a channel and depends on a full software or package update instead.