Google disclosed on October 20, 2026 that the Chrome Root Program received a report on October 17 about private keys for eight eMudhra subordinate certificate-authority certificates generated with insufficient randomness. Google says the weakness could allow forged trusted HTTPS certificates against clients that had not removed trust. This is a certificate-infrastructure incident, not evidence that TLS encryption everywhere failed.
Google describes two stages of response
Google says Chrome corroborated the report and landed a CRLSet block for the affected public keys at 19:45 UTC on October 17. Because the block targets the Subject Public Key Info hashes, Chrome users received protection for certificates sharing those keys without a browser restart. Google says Android devices and Googlebooks received an equivalent Google Play Services update around 22:00 UTC on October 19; restarting can trigger an immediate update.
A second step removes the emSign ECC Root CA - G3 root that signed the compromised certificates from Chrome’s root store. Google planned the broad release for October 27, with prerelease channels earlier. Legitimate certificates chaining to that root may then fail, which is why affected operators are told to obtain and install a certificate under another hierarchy.
Related sources: Google Security: eMudhra intermediate-CA response ↗
Certificate Transparency narrows—but does not erase—the incident boundary
Google reports that no TLS certificates chaining to six of the intermediate authorities appeared in Certificate Transparency logs before the block. It says forged certificates therefore could not have been used against clients that enforce CT, including Chrome and current Android applications that target the latest SDK or opt in.
That is the company’s evidence for CT-enforcing clients; it is not a universal statement about every browser, operating system, embedded device or application. Other root-store operators and maintainers may have different update channels. Google says it coordinated with them and updated CT logs to reject affected chains.
Related sources: Google Security: eMudhra intermediate-CA response ↗ · Chromium: Chrome Root Store FAQ ↗
Canadian site operators should inspect their actual certificate chain
A site owner should check the deployed chain, issuer and expiry on every public hostname rather than infer impact from a vendor name. If the chain reaches the identified root, replace it through the certificate provider and test the served chain from representative clients before the planned removal. Keep the old and new configuration records for incident review, but never publish private keys.
Ordinary users should keep Chrome, Android and Google Play Services current; an unexplained certificate warning should not be bypassed. This article does not claim AI Speed uses an affected certificate or that Google observed fraudulent certificates in CT. The verified event is weak key generation, emergency blocking and a scheduled trust-store change.
Sources and editorial method
We use the linked original statements and reports to distinguish documented facts from our analysis. Company announcements describe their authors’ plans and claims; they are not independent verification of future outcomes. This article is dated and will be revised if material evidence changes. Read our editorial standards and corrections process.
- Google Security: eMudhra intermediate-CA response ↗ — October 20, 2026 disclosure; incident timeline, client protections, CT findings and root-removal plan.
- Chromium: Chrome Root Store FAQ ↗ — Official explanation of Chrome Root Store distribution and scope; reviewed October 21.