Eight compromised eMudhra certificate keys could let someone forge the HTTPS identity of a website. Google and Mozilla say they blocked the affected keys within hours of receiving reports on October 17. Their October 20 announcements expose a less obvious problem: protection delivered to a browser does not automatically reach every application that uses a different certificate trust store.
For ordinary users, the response is to keep browsers current and let their security updates run. Google also says Android users can restart their devices to trigger the relevant protection update. For website operators, there is a separate deadline: Chrome plans to remove the affected upstream root on October 27, potentially breaking legitimate sites that still depend on it.
The keys that vouched for other websites
A website normally presents a TLS certificate to show that the encrypted connection belongs to the domain in the address bar. That certificate sits in a chain: an intermediate certificate authority signs it, and a trusted root ultimately vouches for the intermediate. A client checks that chain before accepting the site’s identity.
The eMudhra incident affected the private keys of eight intermediate CA certificates. Google’s security teams say the keys were generated with insufficient randomness. That makes this a failure in the machinery used to establish trust: someone able to recover such a key could issue a convincing certificate for a domain they do not own.
That alone does not redirect every connection on the internet. To read or change a victim’s traffic in the scenario Mozilla describes, an attacker also needs to intercept the connection, and the victim’s client must still accept the compromised authority. The announcements establish a dangerous impersonation capability; they do not establish that every eMudhra customer, browser user, or past HTTPS session was compromised.
The browser block arrived before the public explanation
Google received the report at 18:05 UTC on October 17. By 19:45 UTC, Chrome had corroborated it and added the affected public-key fingerprints to CRLSet, its distributed certificate-blocking mechanism. Blocking the key matters because the same compromised key cannot escape the block simply by appearing in another certificate.
Mozilla received its report at 20:06 UTC. It used OneCRL, its centrally distributed revocation list, and says distribution was complete by 22:59 UTC for Firefox users with standard configurations. Neither company’s initial browser protection required an update or restart.
Those timings explain an apparent contradiction: an emergency browser release can appear after many users have already been protected. On October 20, Mozilla announced Firefox 158.0.1 for desktop and Android, alongside ESR 115.43.1 and ESR 153.5.1, to reach the minority whose custom settings could have prevented the OneCRL delivery. Keeping Firefox current covers that additional route.
A protected browser leaves a second question
Applications do not necessarily share a browser’s certificate decisions. A command-line client, a bundled runtime, or another program may use its own CA collection or a copy derived from Mozilla’s store. A successful browser block therefore answers a question about that browser, rather than proving that every program on the device has received the same protection.
Mozilla is also removing the signing root from NSS 3.131.1 to help software that uses its trust store without receiving OneCRL. Google likewise removed emSign ECC Root CA - G3 from the Chrome Root Store for consumers that do not receive CRLSet updates. These broader trust-store changes close a distribution gap that the quick browser response cannot close by itself.
Google says Android devices and Googlebooks received an equivalent protection update through Google Play Services around 22:00 UTC on Monday, October 19. Most Android devices had already received it when Google published its account; restarting the device can trigger an immediate update. That statement should not be stretched into a guarantee about every third-party app’s independently managed certificate bundle.
October 27 is a website certificate deadline
Removing a root affects legitimate certificates too. Google’s announced rollout of the G3 root removal is expected on Tuesday morning, October 27, Pacific daylight time, with earlier delivery on prerelease Chrome channels. A site’s certificate can be genuine and still stop working if its chain depends on that root.
Google tells affected website operators to obtain and install a new TLS certificate under another hierarchy included in the Chrome Root Store. The useful check is the complete deployed certificate chain, including intermediates and root, rather than the certificate’s expiry date alone. If hosting or a certificate provider manages that deployment, ask it to confirm the replacement chain before the cutoff.
Users who encounter a certificate error should not bypass validation or install a new root offered by an unsolicited message. The existing connection-not-private troubleshooting guide explains other possible causes of such warnings. Obtain browser updates through the browser or its official distribution channel; fake Chrome update pages are a separate malware trap.
The practical distinction is between three jobs: browsers block the compromised keys, application maintainers update their own trust decisions, and site owners replace legitimate chains that will lose trust. Completing one does not demonstrate that the other two are complete.
References
- Chrome and Android Security Teams. “Protecting Chrome and Android Users from Compromised eMudhra Intermediate CA Certificates.” Google, October 20, 2026; accessed October 21, 2026. Response timeline and root-removal guidance.
- Firefox Security Team. “Protecting Firefox users following the compromise of eMudhra intermediate certificates.” Mozilla, October 20, 2026; accessed October 21, 2026. Firefox, OneCRL and NSS protection.
