The compromised eMudhra certificates: what to check beyond the browser

Browsers blocked the compromised eMudhra certificates within hours. Applications, containers and devices do not do it on their own. What to check, and what not to disable.

On 17 October 2026, the Chrome Root Program forwarded a report to Mozilla: the private keys of eight intermediate certificates belonging to eMudhra, a certificate authority based in India, had been compromised. Browsers reacted the same evening. The catch is that the browser is only one of the programs that check certificates. A company's applications, servers, containers and devices do the same, and many of them never find out on their own that a certificate is no longer trustworthy.

This article is for technical teams and the managers who work with them. It explains what happened and what needs checking beyond "have you updated your browser?".

When you open a site over HTTPS, the server presents a certificate that says "I am yourbank.com". The browser cannot verify that claim by itself, so it relies on a certificate authority (CA), which signs the certificate and vouches that it checked who asked for it. Browsers and operating systems keep a list of authorities they trust, and any certificate signed by one of them is accepted.

Authorities do not usually sign with the root key directly, but through intermediate certificates. Whoever holds the private key of a trusted intermediate can sign a certificate for any domain. If they can also intercept traffic (a public Wi-Fi network, a compromised router, an internet provider), they can impersonate any site or service. Cloudflare describes exactly this risk: an attacker could create a fake certificate for any domain and intercept or modify traffic.

According to Mozilla's public incident report, the private keys of eight intermediate certificates could be recovered almost instantly, because their values were very small. Six are website (TLS) certificates trusted by Chrome, Mozilla, Microsoft and Apple. Two are code-signing certificates trusted by Microsoft.

eMudhra's preliminary explanation is a flaw in a key generation ceremony held on 30 April 2025. A faulty script created a second, weak key pair on the security hardware, and that pair was used by mistake because the labels looked alike. Mozilla notes that it has not verified this explanation. eMudhra revoked the eight certificates on 18 October.

• Mozilla blocked the certificates on the evening of 17 October through its remotely updated revocation list. It shipped new Firefox builds on 20 October and then announced the emergency removal of trust in the emSign ECC Root CA - G3 root.
• Chrome forwarded the report and, according to Mozilla, committed to a similar path for the root.
• Apple and Microsoft blocked the certificates on 19 and 20 October respectively, according to the specialist press. We have not yet found an official announcement from either company.

eMudhra says it has no evidence that the weak keys were used before disclosure, and Cloudflare found no signs of exploitation on its services.

Browsers receive revocation lists within hours through a separate mechanism. Cloudflare observes that browser makers could fix the issue "with a flip of a switch", whereas other software has to be patched one program at a time.

In practice, the compromised certificates may still be trusted by:

• server applications that make HTTPS calls to other services (payments, couriers, APIs);
• container images built before the incident, which carry a frozen copy of the authority list;
• runtimes and libraries with their own list of authorities;
• devices and appliances that do not receive regular updates.

Researchers quoted by Help Net Security warn about exactly this. Cloudflare adds that a test from a browser or the command line does not prove that a background service is protected: the check has to go through the application's real connection path.

Apply system updates on servers and workstations. The system's list of trusted authorities usually ships as a separate package, and that package needs updating too.

A Docker image contains its own copy of the authority list from the moment it was built. Rebuild your images from updated base images and restart the containers. Cloudflare recommends reviewing images and any dependencies that bring their own authority lists.

• Node.js updated its list of authorities on 21 October, in versions 22.23.4, 24.22.1 and 26.12.1, alongside other security fixes.
• Go also published a fix on 21 October (CVE-2026-111943, in versions 1.26.10 and 1.27.3) that rejects a set of intermediate certificates no longer considered trustworthy, for cases where the system list is not up to date. The Go advisory does not name eMudhra, but it appeared on the same day.
• For Java, Python, PHP or other platforms, check the advisories from the vendor and from the distribution you use.

If you use client certificate authentication (mTLS) or have manually uploaded trusted authorities to a service, update those lists separately. Cloudflare mentions them explicitly.

Any certificate issued by the eight intermediates, or sitting under the emSign ECC Root CA - G3 root, has to be replaced. According to the Mozilla discussion, eMudhra estimated around 30,000 certificates to migrate, most of them issued automatically. Check the certificates on your websites, origin servers and appliances.

After the updates, certificate errors may appear in applications that relied, directly or indirectly, on an eMudhra chain. The temptation is to turn off certificate verification "until it is sorted". Cloudflare warns that this would remove exactly the protection the updates restore. An error that appears after patching usually shows the fix is working; the answer is to replace the certificate, not to bypass the check.

1. Update operating systems, including the package with the list of authorities.
2. Rebuild container images and restart services.
3. Update runtimes (Node.js, Go, Java, Python) to their October releases.
4. Update manually uploaded authority lists and those used for mTLS.
5. Replace any certificate issued under the affected eMudhra chains.
6. Test along the application's real connection path and do not disable TLS verification.

At ME Digital we review container images, runtimes and certificate chains as part of our security and updates services. If you would like us to look at your infrastructure, get in touch.

• Mozilla Bugzilla 2083449, eMudhra: Private key compromise of Intermediate Certificates
• Cloudflare, 8 eMudhra certificates are compromised. Here's what you need to know
• Node.js, Wednesday, October 21, 2026 Security Releases
• Go Vulnerability Database, GO-2026-6809 (CVE-2026-111943)
• Help Net Security, eMudhra security blunder left trusted CA signing keys exposed to anyone
• The Register, Indian certification authority eMudhra's private keys compromised