Chrome will remove eMudhra’s emSign ECC Root CA - G3 from the Chrome Root Store on the morning of Tuesday, October 27, 2026 (Pacific time), after private keys for eight intermediate certificates under that root turned out to be recoverable by anyone. Google’s Chrome and Android security teams set out the timeline in an October 20 post, and told website operators whose certificates chain to that root to replace them immediately.

The intermediates themselves were blocked by the major browsers within hours of the October 17 report. The root removal is the step that can break legitimate websites, and it is the one with a date still ahead.

What went wrong

A certificate authority’s intermediate certificate is the key that signs ordinary website certificates. Whoever holds that private key can issue a certificate that browsers accept for any domain.

According to Google, the private keys of eight eMudhra subordinate CA certificates “were generated with insufficient randomness”, which let anyone forge trusted HTTPS certificates against clients that still trusted those CAs. The Chrome Root Program received the report from a security researcher at 18:05 UTC on Saturday, October 17. Mozilla says in its security blog post that its own report arrived at 20:06 UTC the same day.

eMudhra’s incident statement says the eight intermediates were created in a key generation ceremony on April 30, 2025, and that a key wrap/unwrap step produced a second, weak set of keys alongside the strong ones. The weak keys were the ones published. The company says it revoked all eight intermediates on October 18, that seven were never used in production and that none had issued a certificate. It has not yet published a confirmed root cause.

How browsers and Cloudflare responded

  • Chrome: a CRLSet update at 19:45 UTC on October 17 blocked the affected keys without a browser update or restart. Android devices received an equivalent update through Google Play Services around 22:00 UTC on Monday, October 19. Google says no TLS certificates chaining to the six TLS-issuing intermediates had been logged to Certificate Transparency before the block, so Chrome, which enforces Certificate Transparency, could not have been fooled by a forged certificate from them.
  • Firefox: Mozilla blocked the certificates through OneCRL, with distribution complete for standard configurations by 22:59 UTC on October 17. On October 20 it released Firefox 158.0.1 for desktop and Android, Firefox ESR 115.43.1 and ESR 153.5.1, and it is removing the signing root from its NSS trust store in NSS 3.131.1. Current version numbers for every major browser are in our browser release tracker.
  • Cloudflare: in its October 20 write-up, Cloudflare says it learned of the issue around 17:00 UTC on October 19, shipped updates to the Cloudflare One Client and 1.1.1.1 app at 02:00 UTC on October 20 and to Cloudflare Tunnel (cloudflared 2026.10.2) at 09:15 UTC, and finished CDN and server-side Zero Trust mitigations at 19:20 UTC. Its review had not found active exploitation on its services.

Who still has work to do

Browsers could switch trust off remotely. Much other software cannot. Cloudflare’s post warns that an API client may hand certificate checks to an HTTP library, a language runtime, the operating system or a bundled trust store, so updating one SDK may not change which certificates it accepts. Containers built on old base images and servers with their own trust stores need the patched packages and then a rebuild, reload or restart.

The practical checklist from the sources:

  1. Website operators with a certificate chaining to emSign ECC Root CA - G3 should get a replacement from another CA hierarchy in the Chrome Root Store before October 27, as Google instructs. eMudhra says the root’s distrust affects one customer ecosystem in the United States, and on October 22 it began offering Sectigo-issued certificates as an alternative.
  2. Developers and operators should update the trust stores their software actually uses, including indirect dependencies, then redeploy. Cloudflare advises against silencing new certificate errors by switching verification off.
  3. Cloudflare customers running cloudflared, the Cloudflare One Client or mutual TLS with uploaded CAs should apply the versions and reviews listed in Cloudflare’s table.

Google adds that the Chrome Root Program is “closely investigating” whether eMudhra’s remaining CA certificates should stay in the Chrome Root Store and will post updates on public forums.

Root changes like this one ship through browser channels first: Google says the removal reaches Chrome Canary and Beta before stable. Our explainer on browser release channels shows how that order works.