Browsers Block Eight eMudhra Intermediate CAs After Keys Prove Recoverable: What IT Teams Should Do

The incident affects trust in HTTPS itself, not one website. An intermediate certificate authority (CA) certificate can sign certificates for any domain, so weak keys on those certificates let an attacker impersonate sites to clients that still trust them. Facts below come from the Google Chrome and Android security team, the Cloudflare security team and SecurityWeek reporting, all published October 20 and 21, 2026.

The CA is eMudhra, a certificate provider based in India. This article summarizes what is confirmed, what remains unclear and what IT teams should check this week.

What Happened

On October 17, 2026, the Chrome Root Program received a report from a security researcher about eight eMudhra subordinate CA certificates. Google confirmed the findings that day and shipped a CRLSet update blocking them, and Mozilla also blocked them, according to SecurityWeek.

• October 17: Mozilla and Google block the certificates in Firefox and Chrome.
• October 19: Apple blocks them, and Android receives an equivalent update through Google Play Services around 22:00 UTC. Cloudflare learns of the issue at about 17:00 UTC.
• October 20: Microsoft blocks the certificates, and Google and Cloudflare publish their advisories.

Google also removed the root that signed the compromised CAs, emSign ECC Root CA - G3, from the Chrome Root Store. That change is expected to reach devices relying on the Chrome Root Store on Tuesday, October 27, 2026, so certificates chaining to that root will stop working in Chrome.

Why the Keys Were Recoverable

Google says the keys were generated with weak entropy, meaning not enough randomness. SecurityWeek quotes Mozilla's Dennis Jackson saying the keys were effectively all zeroes apart from the last byte, so they could be recovered quickly with a standard discrete logarithm method.

eMudhra attributes the problem to a flaw in a script used during a key generation ceremony, which created a second, weaker key pair that was mistakenly used for certificate signing requests. Strong random number generation is a basic requirement in NIST SP 800-90A, and key protection practices are covered in NIST SP 800-57.

Was It Exploited?

No public evidence of malicious use has been reported. Google says no TLS certificates chaining to the affected CAs were logged to Certificate Transparency before the block, so clients that enforce Certificate Transparency, including Chrome, would have rejected forged certificates. Not every client enforces it, so risk remains for others.

Cloudflare says its review found no active exploitation on its services. Treat these as current statements from the vendors, and watch for updates, because investigations like this evolve quickly.

What It Means for B2B SaaS Buyers and IT Teams

The main risk is not browsers, which are already patched, but everything else that validates certificates: servers, containers, mobile apps, command-line tools and embedded devices with their own trust stores. These may keep trusting the blocked CAs until someone updates them.

Teams should also review certificates issued under the affected hierarchy. Cloudflare notes that updating an SDK does not always change the underlying certificate verification policy, so check the HTTP library, runtime, operating system and custom trust configuration. Do not disable certificate verification to clear errors, because that removes the protection.

What to Do Now

Inventory your certificates and trust stores this week, replace any certificate that chains to emSign ECC Root CA - G3, and update clients that need new trust data. Then test the real TLS path of background services, because a browser check may not reflect it.

• Search your certificate inventory for chains to emSign ECC Root CA - G3 and replace them from another trusted hierarchy before October 27.
• Update operating systems, container base images and VPN or zero trust clients to versions that distrust the affected intermediates.
• If you use Cloudflare, upgrade WARP, 1.1.1.1 and cloudflared (version 2026.10.2 or later) as its advisory describes.
• Review mutual TLS trust stores and any uploaded client-certificate CAs.
• Use Jackson's public check tool, linked from the SecurityWeek report, to test whether a client still trusts the CAs.

Related SaaSPodium Categories

Certificate lifecycle management and key governance matter more after incidents like this one, because teams must replace certificates quickly. Compare vendors in SSL Certificates Software, such as DigiCert and Let's Encrypt, and in Encryption Key Management Software. Organizations that sign documents with certificate-based digital signatures should also review Electronic Signature Software.

For other recent patch-now items, see our report on the PHP critical remote code execution flaws.

Frequently Asked Questions

Do I need to do anything if I only use Chrome?
Chrome users are already protected by the CRLSet update and do not need to restart or update the browser for it to take effect, according to Google. Server operators with certificates chaining to emSign ECC Root CA - G3 must replace them before the root removal reaches devices on October 27, 2026.

How do I know if my certificates are affected?
Check whether any certificate chains to emSign ECC Root CA - G3 or the eight affected intermediate CAs. Review your certificate inventory, scan public endpoints, and ask your certificate provider. eMudhra has said it will help subscribers migrate off the root.

Should we replace our certificate provider?
This incident does not by itself require a vendor change, but it is a good prompt to review your provider's key generation controls and your ability to replace certificates quickly. Ask about audit reports, incident response and automated renewal before you renew.