eMudhra TLS Certificate Distrust: What Site Owners Should Do

Chrome will stop trusting eMudhra TLS certificates that chain to the emSign ECC Root CA - G3 on October 27, 2026. The Indian certificate authority’s private keys for eight intermediate CAs turned out to be guessable in seconds. Site owners using this chain need to replace their certificates now.

Private keys worth less than 256

Every time a browser opens an https site, it checks that site’s TLS certificate. Certificates are issued by certificate authorities (CAs), usually by an intermediate CA whose own certificate is signed by a root CA. Browsers and operating systems ship a list of trusted roots, so anyone holding an intermediate CA’s private key can issue a certificate that looks valid for any domain.

At 18:05 UTC on October 17, 2026, a researcher told the Chrome Root Program that the private keys of eight eMudhra intermediate CAs could be recovered. According to Help Net Security, the researcher, known as Wayne, spotted the problem while reviewing the CCADB database and proved it by signing a message with each key. The report also went to Apple, Microsoft, Mozilla and eMudhra.

A P-384 private key should be a very large random number. All eight eMudhra keys were below 256, which means an attacker needed at most 256 guesses. Security researcher Scott Helme recovered every key from the public certificates on his laptop in under a second. One of them was the number 4.

The eight intermediates came from a batch created on April 30, 2025. Six issue TLS certificates for websites and two are for code signing. In its incident report on Mozilla’s Bugzilla, eMudhra said a faulty script in its key generation ceremony created a second, weak set of key pairs. Those keys carried labels similar to the correct ones, and staff picked them when preparing the certificates.

How browsers and software responded

Browsers and operating systems

In an official Google post, the Chrome team said it confirmed the findings and shipped a CRLSet update at 19:45 UTC the same day. CRLSet is a blocklist Chrome delivers in the background, so users were protected without updating or restarting the browser. Android devices and Googlebooks received an equivalent block through Google Play Services at about 22:00 UTC on October 19.

Mozilla blocked the intermediates through OneCRL and decided on October 20 to remove trust in the emSign ECC Root CA - G3. Apple blocked the certificates on October 19 and Microsoft on October 20. Chrome expects to remove the same root for every device that relies on the Chrome Root Store on the morning of Tuesday, October 27, Pacific time.

Google said no TLS certificate from the affected intermediates appeared in Certificate Transparency logs before the block, so no forged certificate could have been used against Chrome or other clients that enforce CT. CERT-In, India’s computer emergency response team, said it had seen no malicious use of the keys as of October 21. Whether anyone found the weak keys during the roughly 17 months before the report remains unknown.

Software outside the browser

The harder problem is software that never checks whether a certificate was revoked. Programs that rely on a bundle such as Python’s certifi keep trusting the old chain until the bundle changes. The Hacker News tracked the fixes so far:

• Go 1.27.3 and 1.26.10 reject chains containing the eight keys, but only once programs are rebuilt.
• Node.js 26.12.1, 24.22.1 and 22.23.4 update the root list. The same releases fix the Brotli flaw covered in our Node.js Brotli vulnerability article.
• Python certifi 2026.10.19 and Composer ca-bundle 1.6.0 and 1.4.16 drop the affected root or intermediates.
• Ubuntu and Debian ca-certificates packages remove the emSign ECC Root CA - G3. Red Hat rates the issue Important and says containers built from RHEL and UBI images should be rebuilt once base images are updated.

About 30,000 legitimate certificates are caught up

Removing a root means valid certificates beneath it stop working too. Chrome’s count of public CT logs, cited by The Hacker News, found about 30,800 unexpired certificates chaining to the emSign ECC Root CA - G3 as of October 21. eMudhra puts the number that must move at about 30,000, roughly 97 percent of them issued through the ACME protocol.

Some 99.9 percent of those certificates were issued through InCommon, the certificate service Internet2 runs for US higher education. Cornell, for one, reported more than 300 affected certificates and asked holders to switch to RSA certificates, which chain to eMudhra’s separate G1 root. Mozilla has not removed trust in the G1 root for now, while Chrome is still evaluating whether eMudhra’s remaining roots should stay.

Chrome also flagged a practical catch for automated renewals. Standard ACME clients do not replace a certificate outside their renewal window unless they support ACME Renewal Information (ARI) or someone intervenes manually. A server that depends on automatic renewal may still be serving the old certificate on October 27.

eMudhra is leaving the global TLS business

On October 22, eMudhra announced it will exit the global SSL/TLS certificate business. According to CyberScoop, chairman V. Srinivasan said the affected certificates were revoked within 14 hours, the company’s infrastructure was not compromised and no data was breached. The business brings in about 1 percent of eMudhra’s revenue. Revocation services will keep running until every certificate it issued has expired or been replaced, and its digital signature and eSign services continue.

What this means for site owners

Government, university, hospital and e-commerce sites in Indonesia are unlikely to use this chain, but checking takes only a few minutes. The side that gets overlooked is the client: mobile apps, backend services and IoT devices that call third-party APIs with a built-in root list that rarely gets updated.

Steps to take now:

1. Check the chain on every domain. Run openssl s_client -connect yourdomain:443 -showcerts and look for emSign in the issuer lines. Repeat for API subdomains, admin panels and mail servers.
2. Replace certificates that chain to the emSign ECC Root CA - G3. Google says operators “must immediately acquire and install a new TLS certificate from another PKI hierarchy” in the Chrome Root Store. If you use ACME, force a reissue, because the automatic renewal date may not fall before October 27.
3. Update root bundles on servers and containers. Install your Linux distribution’s ca-certificates update, update certifi or ca-bundle in Python and PHP projects, then rebuild container images.
4. Rebuild Go programs and update Node.js. The Go fix only takes effect once a program is recompiled with the new release. For mobile apps and devices that carry their own root list, plan a version update.

It is also worth publishing a DNS CAA record, which limits which CAs may issue certificates for your domain, and monitoring Certificate Transparency logs for certificates you do not recognize. Teams that manage many domains can add certificate chain checks to routine monitoring, as part of their cybersecurity services or the release process for web application development.

Frequently asked questions

Are certificates from other CAs affected?

No. Only the emSign ECC Root CA - G3 and eMudhra’s eight intermediate CAs are being distrusted. Google said it reviewed its root stores and found no other keys with the same weakness.

Do ordinary users need to do anything?

Chrome and Android users are already protected through automatic updates. Google says Android users can restart their device to trigger the update immediately. Users of other browsers should keep their browser and operating system up to date.

What if my site uses an RSA certificate from eMudhra?

RSA certificates chain to the G1 root, which Mozilla has not distrusted, so they still work today. Because Chrome is still reviewing eMudhra’s other roots and the company is leaving the global TLS business, plan a move to another CA early.

Closing thoughts

The eMudhra incident shows that HTTPS security depends on the discipline of every CA in the chain, and that a distrust decision can reach sites that did nothing wrong. If you want to review certificates and root bundles across your organization’s applications, the Merakit team can help you build the checklist and the monitoring around it.

Sources

• Google: Protecting Chrome and Android Users from Compromised eMudhra Intermediate CA Certificates (October 20, 2026)
• Mozilla Bugzilla 2083449: eMudhra, Private key compromise of Intermediate Certificates (opened October 18, 2026)
• The Hacker News: Eight eMudhra CA Keys Compromised, Triggering Emergency Fixes (October 20, 2026, updated October 21, 2026)
• Help Net Security: eMudhra security blunder left trusted CA signing keys exposed (October 21, 2026)
• The Hacker News: eMudhra to Exit Global SSL/TLS Business (October 22, 2026)
• CyberScoop: eMudhra kills its certificate business after researchers cracked its private keys (October 22, 2026)