Google plans to remove emSign ECC Root CA – G3 from the Chrome Root Store on Tuesday morning, October 27, a change that can make some otherwise legitimate websites and services fail certificate checks in Chrome and other software that relies on Google’s trust store.
The removal follows the discovery of eight eMudhra intermediate certificate-authority keys generated with critically weak randomness. Six could authorize TLS certificates and two were for code signing. Browser vendors blocked the affected public keys within hours, eMudhra revoked the intermediates on October 18, and public disclosures have not established malicious use. The more immediate problem for administrators is different: Google is distrusting the root above those intermediates, so legitimate certificates that still chain to it need to move.
eMudhra announced on October 22 that it will leave the global public SSL/TLS certificate business. It says replacement certificates will be provided free through partners during the transition, while its G1 RSA roots, revocation services and certificate-status services will continue operating until issued certificates expire or are replaced.
Who needs to act before October 27
Operators should check any public TLS certificate issued by eMudhra or its emSign brand, including certificates bought through resellers. The relevant question is not whether a leaf certificate was issued by one of the eight weak intermediates. Google reported that no TLS certificates chaining to the six affected TLS intermediates appeared in Certificate Transparency logs before the block. The operational question is whether the certificate presented by a site ultimately chains to emSign ECC Root CA – G3, which Chrome is removing.
The scope extends beyond a company’s primary website. Inventory API endpoints, customer portals, mail gateways, VPN and remote-access portals, CDN custom domains, load balancers, Kubernetes ingresses, appliance management interfaces and externally reachable development systems. Also check certificate pinning, Java or application-specific trust stores, containers, embedded devices and mobile apps that do not inherit browser trust updates cleanly.
Mozilla has already moved to remove the same root in NSS 3.131.1. Firefox users with normal settings received an earlier OneCRL block without updating or restarting; Mozilla also released Firefox 158.0.1, Firefox ESR 115.43.1 and ESR 153.5.1 for configurations that may not receive OneCRL updates. Google delivered an equivalent block to supported Android devices through Google Play services and says a restart can trigger the update.
How to check a certificate chain
Start with the certificate viewer in a current browser. In Chrome, open the site, select the connection controls beside the address, open the certificate information and inspect the certification path. Look for emSign ECC Root CA – G3 at the top of the chain. Test from outside the corporate network as well, because a proxy, CDN or edge load balancer may present a different certificate from the origin server.
Administrators can also inspect the chain a server sends with OpenSSL:
openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null 2>/dev/null | openssl crl2pkcs7 -nocrl -certfile /dev/stdin | openssl pkcs7 -print_certs -nooutReplace example.com with the real hostname. The command prints certificate subjects and issuers, but servers generally do not send the root certificate itself. If the output stops at an eMudhra or emSign intermediate, use a certificate-chain analyzer, inspect the path in a browser, or ask the issuing CA or reseller to identify the root hierarchy. Do not assume a certificate is unaffected simply because the root name is absent from the server’s transmitted chain.
Organizations with certificate-management platforms should search their inventory by issuer, authority key identifier and chain, then confirm results against each endpoint. Mozilla’s incident discussion estimated that roughly 30,000 certificates required migration and that about 97% had been issued through ACME. That makes automation helpful, but it also creates a trap: a normal ACME client may wait for its configured renewal window instead of replacing a still-valid certificate before the trust deadline.
Reissue now, then verify the chain actually changed
If a certificate chains to the affected root, request a replacement from a different hierarchy already trusted by the clients that matter to the service. eMudhra says it is moving customers and providing replacements through partners. Administrators can also use another certificate authority that meets their validation, policy and compatibility requirements.
Generate a fresh private key and certificate signing request where operationally practical. Install the new leaf certificate with the correct intermediate bundle on every terminating endpoint, including failover nodes and secondary regions. A new leaf certificate alone is not enough if the server continues to send an intermediate chain that leads clients back to the removed root.
For ACME deployments, force a renewal or change the configured certificate profile or chain rather than waiting for an automatic timer. Check whether the CA supports a preferred-chain setting, and make sure the resulting chain leads to the intended replacement root. Staged systems deserve the same treatment; an expired or distrusted certificate on a dormant disaster-recovery endpoint often appears only when it is needed.
After deployment, verify from multiple networks and client families:
- Chrome Stable, Beta or Canary on a clean device;
- Firefox and a current NSS-based client;
- Android and iOS devices relevant to the user base;
- command-line clients such as
curland OpenSSL using the production trust store; - Java, .NET or appliance clients with separate certificate stores;
- monitoring probes that validate the full chain rather than only the expiry date.
Check every hostname on the certificate, not only the main domain. Confirm that redirects, IPv4 and IPv6 paths, regional edges and CDN points of presence serve the new chain. Keep the old configuration available for rollback, but do not roll back to a chain that depends on the distrusted root.
Update clients and trust stores too
The weak intermediate keys could have allowed forged website or code-signing certificates against clients that still trusted them. Google says Certificate Transparency enforcement protected Chrome and opted-in Android applications because no certificates from the six TLS intermediates were logged before the block. That protection does not cover every TLS client, private application or older device.
Patch browsers, operating systems, language runtimes, containers and appliances so they receive current revocation and trust-store data. Rebuild long-lived container images that carry old CA bundles. For managed fleets, confirm that browser policies do not disable component updates and that TLS inspection products are not reconstructing a path through the removed root.
The underlying elliptic-curve algorithm was not broken. CERT-In reports that the P-384 private-key values were smaller than 256, making them recoverable almost immediately from the public keys. eMudhra attributed the problem to a key-ceremony wrap/unwrap test that produced a second weak set of keys; similarly labeled keys were then used for certificate requests. Mozilla’s public incident review is still pressing for a full explanation of the controls and the migration process.
What eMudhra’s exit changes
eMudhra says public SSL/TLS contributed about 1% of its global revenue. Its domestic Indian digital-signature and eSign infrastructure, enterprise PKI products and other identity services are separate and are not included in the withdrawal. Sectigo, which had cross-signed the affected eMudhra intermediates, revoked those cross-certificates and other eMudhra intermediates it had cross-signed; Sectigo says its own customer certificates and systems were not compromised.
For administrators, the exit reinforces the need to treat certificate-authority continuity as an operational dependency. Record both the issuer and the root path in the certificate inventory, test emergency reissuance, and monitor root-program announcements. Expiry monitoring alone will not catch a certificate that remains within its validity period but loses client trust.
