eMudhra Certificate Compromise: What Happened and What You Should Do

On Saturday, October 17, 2026, a security researcher disclosed a serious vulnerability in eight eMudhra intermediate Certificate Authority (CA) certificates: their private keys had been generated with insufficient randomness, making them practically trivial to recover. Anyone who obtained a private key could forge trusted HTTPS certificates to impersonate any website.

Here's what happened, how the ecosystem responded, and what you should do if you're affected.

What Went Wrong

eMudhra, an Indian certificate authority trusted by major root programs (Chrome, Firefox, Apple, Microsoft, and Mozilla), issued eight intermediate CA certificates with private keys that lacked proper cryptographic entropy.

According to eMudhra's official statement, the root cause was an error in a script used during its Key Generation Ceremony in April 2025. The script generated a second set of weaker keys that were mistakenly selected for certificate signing because they had labels similar to the properly generated keys.

The weakness was stark: as BleepingComputer reported, all eight certificates used P-384 private keys generated in April 2025 with values smaller than 256. An attacker could recover a private key by testing just 256 possible numbers. Security researcher Flüpke demonstrated the issue by publishing one of the compromised private keys on GitHub — the key for eMudhra's "EM OV TLS CA - G3C" certificate had a value of just 4.

With a recovered private key, an attacker could issue fraudulent TLS certificates for any domain, intercept encrypted traffic, and impersonate websites to clients that still trusted the compromised CAs.

The Timeline

How Browser Vendors Responded

Browser maintainers acted quickly because they control the trust stores their users rely on.

Google Chrome and Android

Chrome blocked the affected certificates by SPKI hash via a CRLSet update at 19:45 UTC on October 17 — less than two hours after receiving the report. Because CRLSet blocks by SPKI (Subject Public Key Info), Chrome users were immediately protected against all certificates sharing those compromised keys, without requiring a browser update or restart.

Android devices received an equivalent update through Google Play Services around 22:00 UTC on Monday, October 19.

Chrome also removed the emSign ECC Root CA - G3 root certificate (which signed the compromised intermediates) from the Chrome Root Store, expected to roll out October 27. Certificates chaining to that root will cease to function in Chrome until their operators migrate to another trusted hierarchy.

Mozilla Firefox

Mozilla blocked the certificates through OneCRL, Firefox's centralized revocation list, by 22:59 UTC on October 17 — under three hours after disclosure. Firefox 158.0.1 and ESR updates distributed the protection to users whose custom settings had blocked the OneCRL update. Mozilla also removed the root from NSS 3.131.1, protecting other applications that use Mozilla's trust store.

Cloudflare

Cloudflare published security updates for Cloudflare One Client, WARP, and cloudflared on October 20, with CDN and server-side Zero Trust mitigations fully deployed by 19:20 UTC the same day.

Was Anyone Actually Harmed?

The good news: there is no evidence that fraudulent certificates were issued or used in the wild.

Key reasons the impact was contained:

1. Certificate Transparency (CT): No TLS certificates chaining to the six compromised intermediate CAs were logged to CT before Chrome's blocking action. Since Chrome enforces CT for all publicly trusted certificates by default, any fraudulent certificate would have been rejected by Chrome anyway.
2. Fast response: Browser vendors blocked the keys within hours of disclosure.
3. Limited production use: eMudhra stated that most of the affected intermediate certificates were never used in production.

However, the weak keys existed since April 2025 — over a year before discovery — so the theoretical window of abuse was significant.

What This Means for You

If You Operate a Website with an eMudhra Certificate

Check whether your TLS certificate chains to emSign ECC Root CA - G3 or any of the eight compromised intermediates. If it does:

1. Immediately acquire and install a new TLS certificate from another PKI hierarchy included in your users' root stores (e.g., DigiCert, Sectigo, Let's Encrypt, Google Trust Services).
2. Do not wait for browser breakage — Chrome removes the root October 27, and other root programs are following suit.

eMudhra is issuing replacement certificates from an alternate, independently operated CA hierarchy and is offering Sectigo-issued certificates as an alternate option to all customers.

If You're a System Administrator or Developer

The compromise affects more than browsers. Many software stacks rely on the WebPKI for TLS verification:

• Linux distros: Arch, Gentoo, Alpine, FreeBSD, Chainguard, and others have or are preparing ca-certificates updates
• Programming languages: NSS 3.131.1, curl CA bundle, Go 1.27.3/1.26.10, Python certifi, Rust webpki-roots, Node.js, Bun, Electron, and more
• macOS: The built-in /usr/bin/curl utility may continue trusting the compromised certificates because its certificate bundle does not check revocation information

Mozilla's Dennis Jackson has crowdsourced a list of commonly patched packages. Upgrade your dependencies, rebuild affected container images, and restart or redeploy applications as needed. A successful browser test does not prove a background service is protected — validate through the application's actual TLS path.

If You're an Everyday User

You likely don't need to do anything. Chrome, Firefox, and Android have already pushed protections automatically. Just make sure your browsers and operating systems are up to date.

Lessons for the WebPKI

This incident reinforces a few hard truths about public-key infrastructure:

1. Key generation ceremonies matter. A single script error in a key generation process can undermine trust for millions of users. The wrap/unwrap step that caused this incident is now under full review at eMudhra, with plans to adopt AI-based tooling alongside conventional safeguards.
2. Fast revocation mechanisms save time. CRLSet and OneCRL let browsers protect users in hours, not weeks. Projects like upki aim to bring similar agility to non-browser systems, where trust stores are often static and slow to update.
3. Certificate Transparency is a safety net. CT logging meant that even if an attacker had issued fraudulent certificates, CT-enforcing clients like Chrome would have rejected them.

Bottom Line

The eMudhra compromise was serious but well-contained. Browser vendors responded within hours, no fraudulent use has been detected, and affected customers are being migrated to replacement certificates. If you run a website or manage infrastructure that depends on eMudhra-issued TLS certificates, rotate them now — before the root removals take effect.

Trust in the WebPKI is rebuilt through action, not statements. eMudhra has committed to publishing its root cause and investigation findings openly, and the root programs will continue evaluating eMudhra's remaining CA certificates. We'll keep watching this space.