eMudhra certificate compromise: find and replace affected TLS chains

The eMudhra certificate compromise means some TLS certificates will stop working in Chrome. Google reported that private keys for eMudhra subordinate CA certificates were generated with insufficient randomness. Chrome blocked those intermediates on 17 October 2026 and set the removal of emSign ECC Root CA - G3 from its root store for 27 October (PDT).

Google says no TLS certificates chaining to the affected intermediates were logged to Certificate Transparency before the block. There is no public evidence of fraudulent certificates in use. The practical risk is your own legitimate certificate losing trust.

Sources checked on 26 October 2026. Dates, availability and vendor figures can change; confirm the linked primary sources before acting.

What the eMudhra certificate compromise affects

Certificates that chain to emSign ECC Root CA - G3 are affected. Google told site operators with such certificates to install a new one from another PKI hierarchy immediately.

Keep two things apart. The subordinate CAs had the weak keys, and Chrome blocked them first through a CRLSet update that needed no browser restart. The root removal then withdraws trust from everything beneath it, including legitimate certificates. Google's summary counts eight subordinate certificates; the same post later refers to six intermediates, so check the Common CA Database list rather than a number.

Android received equivalent protection through Google Play Services. eMudhra says it will help affected subscribers migrate. Google is still evaluating eMudhra's other CA certificates.

How to check your certificate chains

Check the chain each endpoint actually serves, not the certificate you think you bought. Run this against every public hostname:

openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null 2>/dev/null | grep -E "s:|i:"

Look for eMudhra or emSign in the issuer lines. Repeat for each CDN edge, load balancer, API gateway and mail server, because each can hold a different certificate. Include internal services that Chrome-based clients or Android apps call.

Replace and deploy the new certificate

Order a replacement from a CA in a different hierarchy that is in the Chrome Root Store. Then install the full new chain, including intermediates, everywhere the old one lived.

1. Generate a new private key; do not reuse the old one.
2. Request the certificate and validate the domain.
3. Deploy to every endpoint found in the inventory, starting with the busiest.
4. Re-run the openssl check and confirm the new issuer on each hostname.
5. Revoke the old certificate once nothing serves it.

Monitor after the change

Watch for handshake failures and expiry. A missed endpoint shows up as TLS errors from Chrome and Android users.

Track error rates at the CDN and load balancer for a week. Add the new certificates to expiry monitoring. Subscribe to Certificate Transparency alerts for your domains so you see any certificate issued for them.

Our verdict: if any chain shows the emSign ECC root, replace it today; a forgotten endpoint is the main risk. For a TLS audit or a managed migration, see our server deployment and cloud setup and maintenance and support services. Related: our Ubuntu server security checklist.

Sources and further reading

• Protecting Chrome and Android users from compromised eMudhra intermediate CA certificates — Google

Image credits

Explanatory diagrams: Cloudsoft Zone, CC BY-SA 4.0. Featured photograph: U.S. Department of Agriculture Lance Cheung/Multimedia PhotoJournalist, Public domain, via Wikimedia Commons. Your connection is not private notice in the Ecosia browser (February 2021) 01: Ecosia, GmbH., Public domain, via Wikimedia Commons.