emSign root distrusted: how to find and replace affected TLS certificates and trust stores on AWS

• 17 October 2026, 18:05 UTC. Google's Chrome Root Program received a report that the private keys of eight eMudhra subordinate CAs were generated with insufficient randomness, "enabling anyone to forge trusted HTTPS certificates".
• 17 October 2026, same day. Chrome blocked the affected intermediates through a CRLSet update at 19:45 UTC. Mozilla's OneCRL block reached Firefox users with standard configurations by 22:59 UTC.
• 18 October 2026. eMudhra revoked the eight intermediates, according to eMudhra and CERT-In.
• 20 October 2026. Mozilla announced that NSS 3.131.1 removes the root that signed the intermediates, and Google announced the removal of emSign ECC Root CA - G3 from the Chrome Root Store.
• 21 October 2026. CERT-In issued advisory CIAD-2026-0050, "Compromise of eMudhra Intermediate CA Certificates".
• 22 October 2026. eMudhra announced that its board had decided to withdraw from the global SSL/TLS certificate business.

Google says no TLS certificates chaining to the six affected TLS intermediates were logged to Certificate Transparency (CT) before its block. In eMudhra's incident statement, the company says, based on its investigation to date, that the affected intermediates had not issued publicly trusted end-entity certificates. CERT-In says that as of 21 October 2026 the public disclosures "do not establish confirmed malicious exploitation" of the keys. Mozilla said on 20 October that multiple individuals had independently recovered the private keys, and that this led to its emergency removal of trust in emSign ECC Root CA - G3.

• Server certificates that chain to emSign ECC Root CA - G3. Replace them. CERT-In tells administrators to replace even otherwise legitimate certificates under that root if the relevant clients will no longer trust them.
• Other eMudhra TLS certificates, for example under emSign Root CA - G1. eMudhra says its G1 roots remain active, and Mozilla said it was not removing trust in emSign Root CA - G1. But eMudhra is leaving the global TLS business and Google says it is closely investigating whether eMudhra's remaining CA certificates stay in the Chrome Root Store, so plan a move.
• Clients and trust stores that missed the block or the root removal. Update them.

Not affected, according to CERT-In and eMudhra: Indian digital signature certificates (DSC) and eSign services. CERT-In notes that these are regulated by the Controller of Certifying Authorities (CCA) under MeitY, and eMudhra says they run on separate infrastructure.

In each AWS account:

1. In every Region you use, list ACM certificates and filter for Type IMPORTED. Check the Issuer and chain for "emSign" or "eMudhra". The InUseBy field shows which resources use each certificate.
2. Check US East (N. Virginia) separately. CloudFront uses ACM certificates from that Region only.
3. List IAM server certificates. Load balancers can use them too.
4. For every load balancer HTTPS listener, check the default certificate and the certificate list used for SNI.
5. For every API Gateway custom domain, note the certificate ARN.
6. From outside AWS, use a machine with an updated trust store that no longer includes emSign ECC Root CA - G3. A machine that still trusts G3 will pass a G3 chain, so "Verify return code: 0 (ok)" proves nothing on its own. For every public hostname, list the certificates the server sends:

   openssl s_client -connect host:443 -servername host -showcerts

   Read the chain to its top. The last issuer line, marked i:, names the root the chain ends at. Then run the check again so that it stops on any verification error:

   openssl s_client -connect host:443 -servername host -verify_return_error

Mark G3 chains "replace now" and other eMudhra chains "plan replacement".

• Request an ACM public certificate. It is issued by Amazon Trust Services, which major browsers and Java trust, and ACM manages renewal when you use DNS validation.
• Get a certificate from another publicly trusted CA and re-import it into the same ACM ARN. AWS says re-importing preserves the certificate's association and its ARN, so the resources that use it stay attached to it. eMudhra says it is offering Sectigo-issued certificates to its customers as an alternative, and is moving affected customers to alternate certificates at no cost.

On load balancers, add the new certificate to the listener's certificate list before you change the default certificate. Then verify the served chain with openssl.

One caveat for API Gateway mutual TLS. AWS states that if a certificate is directly re-imported into ACM for an mTLS domain, "the issuer must stay the same". Changing CA there is a planned change.

Many systems carry their own list of trusted roots. CERT-In tells organisations to review independent trust stores in "programming-language runtimes, container images, TLS libraries, network appliances and embedded systems".

• Mutual TLS trust stores. API Gateway mutual TLS uses a PEM truststore file in Amazon S3 with the full chain to the root. ALB mutual TLS trust stores hold CA bundles. If you trusted emSign ECC Root CA - G3 for client certificates, upload a new bundle without it and update the domain or trust store. AWS states that API Gateway doesn't verify whether a client certificate has been revoked, and points to Lambda authorizers for that check, so what you keep in the truststore bundle matters.
• Container images. Rebuild them on updated CA certificate packages and redeploy.
• Runtimes with their own lists. Update and redeploy runtimes that bundle CA lists, such as Java, Go, Python and Node.js.

Apple notes that each affected TLS intermediate also had a certificate cross-signed by Sectigo, which chains to AAA Certificate Services. Removing emSign ECC Root CA - G3 alone does not remove those paths, and CERT-In asks for cross-signed chains to be reviewed. Check whole chains.

• Keep a certificate inventory with issuer and root for each certificate.
• Prefer ACM-issued certificates where the endpoint allows them.
• Alert on imported certificate expiry with Amazon EventBridge.
• Keep a second CA option ready.
• Monitor Certificate Transparency logs for your domains, as CERT-In advises.
• Keep change evidence. Our guide to CERT-In log retention on AWS covers this. If you want a partner to run AWS operations day to day, see our page on ongoing AWS operations.

CERT-In advisory CIAD-2026-0050 sets out these best practices:

• Apply security updates.
• Update certificate trust stores, and verify that affected chains are rejected.
• Review certificate dependencies on the affected intermediates or emSign ECC Root CA - G3, including cross-signed chains.
• Replace affected certificates with certificates from a trusted, unaffected PKI hierarchy.
• Verify TLS certificates. Do not bypass certificate warnings or disable verification.
• Monitor Certificate Transparency logs for unauthorised issuance.
• Review independent trust stores in runtimes, container images, TLS libraries, appliances and embedded systems.
• Review code-signing trust, because code-signing keys were also affected.

See also CERT-In's AI-agents advisory on AWS, and API security for payouts.

Upvantix is an AWS Select Tier Services Partner. Our AWS security review covers security posture and architecture, and configuration, logging and detection. It produces a risk-ranked remediation and optimization backlog, followed by approved implementation and validation. For this event, the review can include a certificate and trust-store inventory and a replacement plan. We do not issue or resell certificates and we do not give legal or regulatory advice.

Talk to us about a certificate and trust-store review of your AWS accounts.