Compromised eMudhra certificates: Chrome distrusts emSign ECC Root CA - G3 on 27 October 2026. How to check your sites

The private keys of eight eMudhra intermediate certificates turned out to be guessable. Browsers blocked them within days, and Chrome is now removing the root behind them. Most sites are not concerned, but the ones that are have until Tuesday 27 October.

What happened

Google, Mozilla and Cloudflare each published a timeline on 20 October 2026. Times are in UTC.

The cause is unusual. Ars Technica reports that the recovered private keys were tiny numbers (4, 56, 66, 115 and so on) instead of 384-bit values. eMudhra says the keys came from a key generation ceremony held on 30 April 2025, where a flaw produced a second set of weak keys alongside the strong ones, and the weak ones were used. eMudhra also states that its infrastructure was not compromised.

Google, Mozilla and the incident page all report that no certificate chaining to these intermediates appeared in Certificate Transparency logs before the block. That means CT-enforcing browsers (Chrome, Firefox, Edge, Safari, according to the incident page) could not have been attacked with a forged certificate. Software that does not enforce Certificate Transparency is another story, which is why the cleanup goes well beyond browsers.

Eight keys, six intermediates: the exact list

Google mentions eight compromised keys, then "these six intermediate CAs". Both figures are right. Of the eight intermediates, six issue TLS (website) certificates and two issue code-signing certificates. BleepingComputer describes Chrome's block as covering "the six compromised intermediates authorized to issue TLS certificates", and the code-signing ones are irrelevant to Certificate Transparency, which is what that sentence is about.

The public list (impacted-intermediates.json on the incident page) has 16 entries for 8 keys, because each intermediate exists twice: once issued by an eMudhra root and once cross-signed by Sectigo's "AAA Certificate Services" root. All 16 are revoked.

Where does emSign ECC Root CA - G3 come in? The same list marks it as a cross-signer of the eMudhra roots above. That is the root Google calls "the root certificate that signed the compromised CA certificates", and the one that leaves Chrome on 27 October. The Sectigo cross-signatures concern these eMudhra intermediates only; none of the sources say that Sectigo's own certificates are affected.

Who is affected on 27 October

Two different groups:

1. 1Certificates issued by one of the eight intermediates. They are already blocked in the major browsers since 17-20 October. eMudhra states that none of these intermediates issued any end-entity certificate, and that only one was deployed in production. If that holds, no website uses one.
2. 2Legitimate certificates that chain to emSign ECC Root CA - G3 through other eMudhra intermediates. These are the ones that stop working in Chrome on 27 October. Google writes that "some legitimate certificates chaining to this root will cease to function in Chrome" and that eMudhra has committed to helping these customers migrate.

In practice, most agency client sites use Let's Encrypt, Sectigo, DigiCert or a hosting provider's certificate and have nothing to do. The check takes a minute per site, and a site that is affected will show a certificate warning in Chrome from 27 October.

Browser by browser

How to check a site

In the browser

Click the icon to the left of the address bar, open the connection or certificate details, then the certificate hierarchy (Chrome: Details tab, Firefox: "View Certificate"). Read every level, from the site certificate up to the root. If "emSign" or "eMudhra" appears anywhere, keep going with the steps below.

With openssl

host=www.example.com
openssl s_client -connect "$host:443" -servername "$host" -showcerts </dev/null 2>/dev/null \
  | grep -E '^ *[0-9]+ s:|^ *i:'

Each s: line is a certificate the server sends and the i: line below it is its issuer. Servers usually do not send the root, so the last i: line names the root the chain ends at. Look for emSign, eMudhra or EM ... TLS CA - G3B/G3C.

To check a list of client domains in one go, put one name per line in domains.txt:

while read -r host; do
  issuers=$(timeout 10 openssl s_client -connect "$host:443" -servername "$host" -showcerts </dev/null 2>/dev/null \
    | grep -E '^ *i:' | grep -iE 'emsign|emudhra')
  [ -n "$issuers" ] && printf '%s\n%s\n\n' "== $host" "$issuers"
done < domains.txt

No output means none of the names checked chains to an emSign or eMudhra certificate. Do not forget other TLS services: for a mail server, add -starttls smtp and the right port (for example mail.example.com:587).

In Certificate Transparency logs

Searching the domain on crt.sh lists the certificates issued for it and its subdomains, with the issuer of each. It shows what was issued, not what is installed, but it is a quick way to spot an emSign certificate on a subdomain you had forgotten.

Behind a CDN

With a CDN, visitors see the CDN's certificate, and your origin server has its own. Cloudflare asks customers in Full (strict) mode to review their origin certificates, because an origin certificate that is no longer trusted breaks the connection between Cloudflare and the server. Test the origin as well (our guide on a valid certificate that still triggers a browser error shows how to test one IP address with the site's name).

What to do if a site is affected

1. 1Get a new certificate from another hierarchy. Google's instruction is to "acquire and install a new TLS certificate from another PKI hierarchy included in the Chrome Root Store". Changing the intermediate file alone does not help when the whole path leads to the distrusted root. Any authority in the Chrome Root Store works, including a free ACME authority if the hosting supports it. If eMudhra offers a replacement, check before installing it that its chain does not end at emSign ECC Root CA - G3.
2. 2Install the full chain (site certificate first, then the intermediates) and reload the web server.
3. 3Test again from outside with the openssl command above. The emSign or eMudhra lines must be gone.
4. 4Repeat on every place that serves the certificate: other IP addresses, origin behind the CDN, mail server, load balancer.
5. 5Do it before Monday 26 October. The removal lands on Tuesday morning in California, which is Tuesday afternoon or evening in Europe, and it can reach Chrome Canary and Beta sooner.

Your servers and apps also trust certificates

The other half of the incident is outgoing traffic. A server that calls a payment API or receives webhooks validates certificates with its own trust store, which may still trust the compromised intermediates. Cloudflare's advice: look beneath the SDK, because verification may be done by an HTTP library, the language runtime or the operating system, and never "fix" new certificate errors by disabling verification.

The incident page keeps a list of patched packages. On 21 October it included Ubuntu and Debian ca-certificates, Alpine ca-certificates 20261020-r0, NSS 3.131.1, the curl CA bundle of 2026-10-20, Python certifi 2026.10.19 and Go 1.27.3 / 1.26.10, with Node.js, Bun and FreeBSD still pending. Update the system package, rebuild container images, and restart the services so they load the new trust store.

A quick checklist

1. 1List every client domain and subdomain that serves HTTPS.
2. 2Run the openssl loop and search the issuers for emSign or eMudhra.
3. 3Check crt.sh for forgotten subdomains, and the origin behind any CDN.
4. 4Replace any affected certificate with one from another authority before 26 October.
5. 5Test again from outside after installing.
6. 6Update ca-certificates and language runtimes on your servers, then restart services.

How to monitor it

Lapsentry connects to each website and reads the certificate it actually serves. It shows the issuer next to each domain, so you can scan a client portfolio for emSign or eMudhra without opening every site. Once a certificate is replaced, the ssl.issuer_changed event confirms that the new one comes from another issuer, and ssl.invalid alerts you if the chain or the host name no longer validates, for example a missing intermediate after the switch. For an origin behind a CDN, the per-address test above remains the way to check.

Start your 14-day free trial: no card required.

What is not confirmed yet

This guide reflects the sources available on 21 October 2026. Still open at that date:

• Apple and Microsoft have published nothing of their own that we could find. The block dates (19 and 20 October) come from the incident page, and neither has said whether it will remove emSign ECC Root CA - G3.
• Firefox and the root. Mozilla removes the root from NSS 3.131.1 but does not name it in its post or say when Firefox itself drops it. The workarounds on the incident page target emSign ECC Root CA - G3, which points to that root.
• The exact hour on 27 October. Google only says "Tuesday morning, PDT".
• eMudhra's other roots. Google says it is "closely investigating the ongoing inclusion of eMudhra's remaining CA certificates" and will post updates on the CCADB public list.

We will update this page if any of these change.

Sources

• Google, Protecting Chrome and Android Users from Compromised eMudhra Intermediate CA Certificates, 20 October 2026.
• Mozilla Security Blog, Protecting Firefox users following the compromise of eMudhra intermediate certificates, 20 October 2026.
• Cloudflare, 8 eMudhra certificates are compromised. Here's what you need to know, 20 October 2026.
• Incident page by Dennis Jackson (Mozilla), eMudhra Intermediate CA Compromise, with impacted-intermediates.json and roots.json, 20 October 2026.
• Ars Technica, The Internet goes on high alert after discovery of 8 compromised TLS certs, 20 October 2026.
• BleepingComputer, Mozilla, Google, Apple block compromised eMudhra CA certificates, 20 October 2026.
• eMudhra, Statement on Recent Certificate Security Incident, 20 October 2026, and press release of 21 October 2026.

FAQ

What is emSign ECC Root CA - G3?

It is a root certificate operated by eMudhra, an India-based certificate authority. According to the public incident list, it cross-signed the eMudhra roots that issued the eight compromised intermediates, and Google calls it the root that signed them. Chrome removes it from the Chrome Root Store on 27 October 2026.

When exactly does Chrome stop trusting it?

Google expects the removal to be released on Tuesday morning, 27 October 2026, Pacific time, for all devices relying on the Chrome Root Store, and sooner on Chrome Canary and Chrome Beta. That is Tuesday afternoon or evening in Europe. Plan to have replaced any affected certificate by Monday 26 October.

How do I know if my site uses an eMudhra certificate?

Look at the certificate hierarchy in the browser, or run openssl s_client with -showcerts and read the issuer lines. If emSign or eMudhra appears at any level, the site is concerned. Repeat for every subdomain and for the origin server behind a CDN.

Why does Google mention eight keys and then six intermediates?

Eight intermediates had weak keys: six issue TLS certificates for websites and two issue code-signing certificates. Google's sentence about six intermediates is about Certificate Transparency, which only concerns the TLS ones.

Can I fix it by changing the intermediate certificate?

No. Google asks site operators to install a new certificate from another PKI hierarchy in the Chrome Root Store. If the certificate itself chains to emSign ECC Root CA - G3, it has to be replaced.

Are Safari and Edge affected too?

Apple and Microsoft block the compromised intermediates, according to the public incident page, but as of 21 October 2026 neither had announced removing emSign ECC Root CA - G3. Replace affected certificates anyway: the Chrome removal alone is enough to break the site for Chrome users.

Does this concern servers and not only browsers?

Yes. Servers, containers and applications that validate certificates with their own trust store may still trust the compromised intermediates. Update ca-certificates and language runtimes, rebuild images, restart services, and never disable certificate verification to silence errors.

More guides

• SSL certificate valid but the browser shows an error: five causes
• Let's Encrypt moves to 64-day certificates: what agencies need to check
• SSL certificate lifetime: 200, 100, then 47 days
• Why Let's Encrypt renewals fail