eMudhra Certificates Distrusted: How to Check Your Sites, Apps and Trust Stores

Browsers and operating systems have stopped trusting a set of eMudhra certificates. Eight of the certificate authority’s intermediate keys turned out to be so weak that anyone could recover them. Google, Mozilla, Microsoft and Apple all moved between October 17 and November 9, 2026. The eMudhra G3 root behind them is gone from Chrome’s and Mozilla’s root stores. Windows and Apple block it too.

Most organizations never bought a certificate from eMudhra, the India-based CA that also sells under the emSign name. The risk for our readers is in two places. One is a site, API or appliance that does use an eMudhra or emSign certificate. The other is software with its own trust list that has not been updated. Think Java runtimes, offline Windows machines, appliances and embedded browsers. This post covers both. Facts are as of November 10, 2026.

The short version: check whether any certificate you serve chains to an emSign root. If one does, replace it with a certificate from another CA now. Then update Java runtimes and make sure offline Windows PCs get Microsoft’s out-of-band update. Ask appliance vendors whether their trust stores still include the emSign roots.

What happened to eMudhra certificates

The record is in Mozilla’s incident bug 2083449. Mozilla says it got a researcher’s report on October 17, forwarded by Google’s Chrome Root Program. The private keys of eight eMudhra intermediate CAs had been generated as tiny numbers. Mozilla’s Dennis Jackson wrote that "The 8 impacted keys all used integers less than 256."

A key like that offers no protection. Anyone who recovers it can issue a certificate for any domain that a client would accept. Microsoft’s Security Response Center says six of the eight intermediates issued TLS certificates and two issued code signing certificates.

eMudhra revoked all eight intermediates on October 18, according to its incident statement. The company says seven were never used in production and the eighth issued no certificates. On October 22, eMudhra announced it would leave the global SSL/TLS certificate business.

Who distrusted eMudhra certificates, and when

Each platform used its own tools. The dates come from each vendor’s own page.

Google’s October 20 post says the CRLSet block reached Chrome users without a restart. A November 4 update to that post covers the G1 root. TLS certificates chaining to emSign Root CA – G1 need a closer look. If their earliest Certificate Transparency timestamp is after November 16, 2026, Chrome 153 and higher will not trust them by default. Older G1 certificates are unaffected for now.

What breaks if you use eMudhra certificates

Say your site, API or mail server uses a certificate that chains to emSign ECC Root CA – G3. Chrome users now see a full-page warning. Google’s instruction to site operators is direct: they "must immediately acquire and install a new TLS certificate from another PKI hierarchy included in the Chrome Root Store."

The G1 hierarchy has a shorter runway. New G1 certificates logged after November 16 will fail in current Chrome. eMudhra’s incident statement says Apple removes G1 on November 30, 2026. We have not seen that date on an Apple page, so treat it as eMudhra’s account.

eMudhra told Mozilla it had about 30,000 certificates to migrate. About 97% came through ACME, the automated renewal protocol. If one of those is yours, you may not know the CA name because a tool picked it.

What breaks in software that keeps its own trust list

Blocking bad eMudhra certificates only helps software that gets the update. Cloudflare’s October 30 measurement post found that up-to-date browsers were mostly protected. It also found that 30 to 40% of embedded browsers like Android WebView still accepted the compromised chain. Across large networks, more than half of its probes still accepted it. Cloudflare said it had seen no sign of the weak keys being used to intercept its connections.

Here is where to look:

• Java. Java runtimes ship their own cacerts file. OpenJDK’s page on the incident covers the fix, below.
• Offline Windows machines. PCs that cannot reach Microsoft’s certificate service never got the October 20 block.
• Appliances and IoT. Firewalls, printers, phone systems and NAS boxes often carry a trust store that updates only with firmware.
• Mutual TLS. Anything that verifies client certificates against an uploaded CA list needs that list reviewed, Cloudflare’s earlier post says.
• Containers. Images built before the fix carry the old CA bundle until you rebuild them. Our explainer on containers covers how images are built.

How to check a site for eMudhra certificates

You can check any public site in a minute. These are standard checks, not steps from a vendor page.

1. In a browser. Open the site, click the icon left of the address, and view the certificate. Look at the issuer and the certification path. Names to watch for include "emSign" and "eMudhra," and intermediates named like "EM DV TLS CA – G3B."
2. From a terminal. Run openssl s_client -connect example.org:443 -servername example.org -showcerts, then search the output for "emSign" or "eMudhra."
3. Across your domains. Search a Certificate Transparency log viewer such as crt.sh for each domain you own. It lists every public certificate issued for it and the issuer.

Check more than the main website. Include APIs, single sign-on endpoints, mail servers, load balancers and partner integrations. For background on how a certificate chain works, see our plain-English guide to HTTPS and TLS.

How to replace eMudhra certificates

If you find one, replace it rather than waiting for the old one to expire. eMudhra’s October 22 announcement says it will contact affected customers to replace certificates "at no cost" through partners. You can also switch to any other CA.

1. Pick a new CA. If you use ACME, change the ACME directory URL in your client to another CA and request a new certificate.
2. Install the full chain. Serve the new leaf certificate and its intermediate, not the leaf alone.
3. Test from outside. Repeat the openssl check above and confirm the new issuer.
4. Update every copy. Load balancers, CDNs and staging servers often hold their own copy of the certificate.
5. Do not turn off verification to make an error go away. Cloudflare’s earlier post warns against exactly that.

Certificate lifetimes are getting shorter anyway, so automation pays off. Our posts on SSL certificate lifespans shrinking and the dual-use certificate deprecation cover the other changes coming in 2027.

Fix Java runtimes and offline Windows PCs

OpenJDK’s page on the compromised certificates says to update standalone runtimes to a release that fixes JDK-8395690, CVE-2026-114820. If your vendor has not shipped one, back up cacerts and delete four root aliases with keytool, then restart the runtime. The page lists the exact commands. It also offers a CheckCerts.java program that tells you whether a runtime is at risk.

Java on Debian and Ubuntu needs an extra step, according to OpenJDK. Updating the packages is not enough because of a long-standing bug. As root, run rm -f /etc/ssl/certs/java/cacerts and then update-ca-certificates --fresh.

For Windows, Microsoft’s response post says connected devices get the change through automatic certificate trust list updates. Disconnected devices need the October 26 out-of-band update. KB5134133 covers Windows 11 24H2, 25H2 and 26H2, and is available from the Microsoft Update Catalog. KB5134130 covers 23H2, KB5134134 covers 26H1 and KB5134125 covers Windows 10 21H2 and 22H2. Our recent post on the expired 2011 Secure Boot certificates covers a related trust list chore for the same machines.

Apple devices and macOS command-line tools

Apple’s support note on the eMudhra intermediates, published November 9, says Apple devices block the compromised certificates automatically. That covers Safari, Mail and apps built on Apple’s frameworks. No software update is needed for that part.

Command-line tools like curl and git use a separate file, /etc/ssl/cert.pem. Apple says macOS 27.2.1, 26.7.3 and 15.8.3 block the certificates there too. They also remove five roots from that file: four emSign roots and the AAA Certificate Services root that cross-signed eMudhra. Apple warns that some websites may then fail verification in tools that rely only on that file. Macs that cannot update can remove the roots by hand, using the Terminal steps on Apple’s page. Apps that bundle their own root list are not covered, so ask those developers.

What we do not know yet

• eMudhra’s root cause. eMudhra has promised a full report through the CA program process. Mozilla’s bug shows questions still open.
• Remaining roots. Google and Microsoft say they are still evaluating eMudhra’s other roots. More removals affecting eMudhra certificates are possible.

We will update this post if any vendor changes its plans.

Frequently Asked Questions