Chrome is scheduled to remove the emSign ECC Root CA–G3 root certificate from its trust store on Oct. 27, potentially disrupting websites whose TLS certificates still chain to that root. Google has warned that some legitimate certificates will stop working in Chrome, including ones that were never issued by the eight compromised eMudhra intermediates.
The root removal follows an Oct. 17 disclosure that eight eMudhra intermediate certificate authority (CA) private keys were generated with insufficient randomness and could be recovered from their public certificates. Chrome blocked those intermediates shortly after receiving the report, but removing the parent root creates a broader certificate replacement requirement.
Public websites whose certificate chains still terminate at emSign ECC Root CA–G3 need replacement certificates from another trusted hierarchy. Organizations must also check outbound integrations, containers, VPNs and applications that manage certificate trust independently.
The priority is to identify affected certificate chains, replace them and verify that dependent services continue working.
How to replace eMudhra TLS certificates affected by Chrome
According to Google, website operators using emSign ECC Root CA–G3 must immediately acquire and install new TLS certificates from another hierarchy included in the Chrome Root Store.
Administrators should follow these steps:
- Build an inventory. Identify internet-facing websites, APIs, load balancers, reverse proxies and other services that present TLS certificates. Include internal services, development tooling, containers and applications that may depend on eMudhra certificates.
- Inspect the actual certificate chain. Run
openssl s_client -showcerts -connect example.com:443 -servername example.com, replacingexample.comwith the hostname being checked. The command displays the certificates presented by the server, which typically do not include the root certificate. - Confirm the trust anchor. Identify the issuing intermediate and determine whether the certificate chains to emSign ECC Root CA–G3. A missing root in the OpenSSL output does not establish that the service is unaffected.
- Obtain a replacement certificate. Reissue affected certificates through another trusted public CA hierarchy. Installing a different intermediate is insufficient if the resulting chain still depends on the removed root.
- Deploy the replacement everywhere. Update redundant servers, gateways, load balancers and other TLS termination points. Confirm that the correct intermediate certificates are installed alongside the replacement.
- Test dependent connections. Verify browser access, API calls and integrations that connect to affected endpoints. These systems may enforce certificate trust differently.
- Monitor after deployment. Watch for TLS validation failures, unexpected certificate warnings and changes to certificate chains.
Certificate replacement should also include a check of the service's TLS configuration. Recent NGINX vulnerabilities illustrate why administrators need to review TLS-related settings and affected server versions rather than assume a valid certificate means the entire connection is secure.
Why a working certificate can still break
The two eMudhra actions are easy to conflate, but they are not the same.
The Oct. 17 emergency block targeted eight specific intermediate CAs whose private keys were recoverable. Six were intended for TLS certificates, while two were used for code signing.
Cisco Talos reported that several of the private keys had values in the single or double digits rather than the expected level of randomness. That made recovering the keys practical and created a risk of certificate forgery.
The flaw originated during an April 30, 2025, key-generation ceremony. eMudhra subsequently revoked the compromised intermediates and stopped issuing new certificates under its G3 root.
Chrome's Oct. 27 action goes further by removing emSign ECC Root CA–G3 itself from the Chrome Root Store.
That means a certificate can be legitimate, unexpired, and unrelated to the eight compromised intermediates yet still fail validation in Chrome if its trusted chain depends on the removed root.
The distinction matters because a certificate's validity period does not override a browser's trust decision. Operators who previously confirmed that their certificates were not issued by the eight compromised intermediates still need to check the parent root.
Chrome, Android and other platforms respond
Google blocked the eight compromised intermediates through Chrome's CRLSet mechanism on Oct. 17. The protection was distributed without requiring a full browser update.
The company separately scheduled the removal of emSign ECC Root CA–G3 from the Chrome Root Store for the morning of Oct. 27, Pacific time. Chrome Canary and Beta received the change earlier.
Android devices received protections against the compromised intermediate certificates through Google Play services on Oct. 19. Google said users could trigger an immediate update by restarting their devices.
Mozilla also blocked the compromised intermediates and moved to remove the affected root from its trust store. Apple began blocking the affected TLS intermediates on Oct. 19.
These actions address different parts of the certificate trust problem. Blocking the compromised intermediates prevents clients from trusting certificates issued through those keys. Removing the root affects a wider set of certificate chains.
Organizations should therefore verify certificate behavior across the browsers, operating systems and applications they support.
Beyond the browser: what security teams should check
Browser and operating system changes do not necessarily reach software that uses its own certificate store or validation process.
NHS England's guidance calls for reviewing dependencies across containers, development tooling, IoT devices, operational technology, mobile applications and internal PKI.
VPNs and other applications that perform their own TLS validation may also need vendor updates.
The Go programming language provides an example. Its security team released Go 1.27.3 and 1.26.10 to block certificate chains involving the compromised intermediates, with the issue tracked as CVE-2026-111943.
Organizations using affected Go versions should review the security advisory and rebuild or redeploy applications where necessary.
Other vendors have assigned separate identifiers to related exposure, including CVE-2026-91403 for Oracle Java and CVE-2026-113470 for Firefox. Administrators should follow each vendor's advisory rather than assume the same fix applies across platforms.
Certificate trust can also be affected by how applications install or manage trusted roots. For example, a recently disclosed Fiddler Classic flaw involved the installation of a root certificate into the Windows trust store. Although unrelated to eMudhra, it illustrates why application-level certificate handling needs separate review.
For the eMudhra incident, application owners should prioritize systems with bundled CA certificates, independently maintained trust stores, or software versions that have not received the relevant vendor protections.
No confirmed exploitation, but reviews continue
The available vendor reports have not established malicious exploitation of the compromised intermediate keys.
Google said no TLS certificates chaining to the six affected intermediates had been logged to Certificate Transparency before Chrome blocked them. As a result, fraudulent certificates from those intermediates could not have been accepted by clients enforcing Certificate Transparency requirements.
Cisco Talos reported no observed malicious incidents involving the compromised certificates as of Oct. 21.
eMudhra has also said it found no evidence of broader infrastructure compromise.
These findings do not establish that misuse was impossible. They describe what the vendors had observed at the time of their statements.
The incident also demonstrates why an HTTPS connection is not, by itself, proof of website legitimacy. As previous reporting on phishing certificates has shown, attackers can obtain valid TLS certificates for domains they control without compromising a certificate authority.
For affected website operators, the immediate task is to replace certificates chaining to emSign ECC Root CA–G3 and confirm that the new chain is trusted. Security teams should then complete the wider dependency review to identify applications and devices that may continue trusting the compromised intermediates.
Google is continuing to review eMudhra's remaining CA certificates. Administrators should monitor vendor advisories for further trust changes rather than assume the Oct. 27 removal concludes the incident.
Also read: Review the patch management tools available for coordinating security updates across affected systems.