eMudhra: The Certificate Scare That Ended in a Day, and the Deadline That Didn’t

Every padlock in your browser rests on a promise. Somewhere, a certificate authority guards a secret key so carefully that nobody else could ever reproduce it.

Last week, that promise failed for eight of eMudhra’s certificates. eMudhra is one of India’s best-known names in digital trust. A flaw in how eMudhra generated its keys left them weak, so weak that, by researchers’ accounts, one of them was simply the number 4.

What happened next is a rare piece of good news in security. The browser makers blocked the certificates the same day, eMudhra revoked them the next, and public records show nobody used them. But the clean-up comes with a deadline. On 27 October, Chrome stops trusting one of eMudhra’s root certificates, and any website still depending on it will start showing errors.

If you run a website, an app with a backend, or integrations with partners’ APIs, read on. If you only use a DSC token for filings, skip to Who is affected: you can relax.

What happened

Read the table from the bottom up and two numbers stand out. The weak keys existed for eighteen months. Once someone reported them, it took the internet about a day to neutralise them.

How it went wrong, in plain terms

A certificate authority’s key is only safe if it is created at random from an enormous range of possibilities. That randomness is what makes it impossible for anyone else to reproduce.

eMudhra says a flaw in one step of its April 2025 key ceremony meant that step produced a second, weak set of keys alongside the strong ones. Key ceremonies are the tightly scripted, witnessed procedures in which certificate authorities create their keys. The weak keys were the ones behind these eight intermediate certificates. A key that isn’t properly random can be worked out from public information, and then it protects nothing.

That’s all you need to know about the mechanics. What matters for your business is what was done about it, and what’s left for you to do.

Was anyone harmed?

As far as anyone can tell, no.

The Google evidence is the strongest, because it doesn’t rely on anyone’s word. Chrome only accepts a certificate that has been recorded in Certificate Transparency logs: public, append-only records that anyone can search. A forged certificate that nobody logged would not have worked in Chrome. A logged one would have been visible to the world. Neither happened.

Who is affected

DSCs and website certificates are both called “certificates”, and both can come from eMudhra, but they live in different trust systems. Indian DSCs chain to the root of India’s Controller of Certifying Authorities (CCA). They are not part of the browser trust stores that are dropping eMudhra’s root. Your finance team can keep filing.

Why this matters for Indian businesses

The meme going round said “don’t use eMudhra”. The real risks are quieter than that.

• The DSC panic. Finance and compliance teams hear “eMudhra compromised” and assume their filings are at risk. They aren’t. Make sure the right people hear that, so nobody cancels tokens or delays filings for nothing.
• Integrations nobody remembers. Payment gateways, SMS providers, logistics partners and government-facing APIs are often wired up once and never revisited. If a partner’s certificate chains to the removed root, the integration fails, and the error lands in your logs, not theirs.
• Old trust lists inside your own systems. Enterprise software often runs on Java, scripts on Python, and backends on Node.js. Each keeps its own list of trusted roots, and each updates on its own schedule.

We saw that last point on our own machines. On 23 October, one of our Ubuntu workstations had already dropped emSign ECC Root CA - G3 from its system trust list. On the same machine, the Java trust store still trusted it, and so did the Python certifi package (version 2026.07.22). The operating system had moved on; the software running on it had not.

Check your exposure in 10 minutes

1. In a browser. Open your site, click the padlock, open the certificate details and look at the certificate hierarchy. Any “emSign” name in the chain needs a closer look.

2. For all your domains at once. List your domains and partner endpoints in this loop and run it from any Linux or Mac terminal:

for d in example.com www.example.com api.example.com; do
  chain=$(echo | timeout 15 openssl s_client -connect "$d:443" -servername "$d" -showcerts 2>/dev/null)
  if [ -z "$chain" ] || ! echo "$chain" | grep -q "BEGIN CERTIFICATE"; then echo "ERROR  $d (no certificate returned)"
  elif echo "$chain" | grep -qi emsign; then echo "CHECK  $d (emSign in the chain)"
  else echo "ok     $d"; fi
done

CHECK means replace that certificate. ERROR means the domain didn’t answer, so check it by hand. On a Mac without timeout, delete timeout 15.

3. In public records. Search your domain on crt.sh (https://crt.sh/?q=example.com). It lists every certificate ever logged for your domain and who issued it. Any certificate you don’t recognise is worth a question.

4. Inside your own systems. Check the trust lists your software uses. A result that mentions G3 means that software still trusts the removed root.

# Linux system trust list (Debian/Ubuntu)
ls /etc/ssl/certs | grep -i emsign

# Java trust store
keytool -list -cacerts -storepass changeit | grep -i emsign

# Python (requests and many other libraries use certifi)
python3 -c "import certifi; print(open(certifi.where()).read().count('emSign ECC Root CA - G3'))"

# Node.js: 22.23.4, 24.22.1 or 26.12.1 and later include the update
node -v

Fix it

1. Replace affected certificates before 27 October

• Get a new certificate from another certificate authority in the Chrome Root Store. A free ACME authority such as Let’s Encrypt works for most sites, or use your commercial CA.
• Install it wherever the certificate actually lives. That might be the web server, but it is often the load balancer, CDN or cloud certificate manager (for example AWS Certificate Manager or Cloudflare).
• Serve the full chain, then re-run the check above.

2. Update trust lists on your servers

• Operating systems: apply the latest ca-certificates updates.
• Java: update the JDK. On Debian or Ubuntu, sudo update-ca-certificates --fresh also rebuilds the Java keystore installed by ca-certificates-java. Check again afterwards.
• Python: upgrade certifi once a release without the root is available, and re-run the check.
• Node.js: upgrade to 22.23.4, 24.22.1 or 26.12.1. This is also an important security release in its own right.

3. Check mobile apps that pin certificates

If your Android or iOS app pins your server’s certificate or its chain, changing the certificate can break the app. Ship an app update that trusts the new chain before or alongside the server change.

What not to do

• Don’t switch off certificate checks to “fix” a broken integration. That means no NODE_TLS_REJECT_UNAUTHORIZED=0, no verify=False, no curl -k. That trades a temporary error for a permanent hole.
• Don’t add the removed root back into a trust store by hand.
• Don’t tell customers to click through a certificate warning. Tell staff never to do it either.
• Don’t cancel DSC or eSign workflows. eMudhra says they are unaffected.
• Don’t wait for 27 October to find out. Errors in production are the most expensive way to run this check.

Detect and verify

After replacing certificates:

• Test from outside. Run each public domain through an external checker such as SSL Labs and confirm the chain no longer mentions emSign.
• Watch for trust errors from 27 October. Search logs and monitoring for the errors each platform shows when it no longer trusts a chain:
  • Chrome: NET::ERR_CERT_AUTHORITY_INVALID
  • Java: PKIX path building failed
  • Python: CERTIFICATE_VERIFY_FAILED
  • Node.js: unable to get local issuer certificate
  A spike in outbound calls points to a partner who hasn’t switched.
• Monitor Certificate Transparency for your domains. Free tools such as crt.sh or Cert Spotter can alert you whenever a new certificate is issued for your domain. It’s the simplest way to learn about a certificate you didn’t ask for.

The lesson beyond this incident

The eMudhra incident will be forgotten in a month. The conditions that make the clean-up painful will not.

• You can’t replace what you can’t find. Keep a list of every certificate you own, where it is installed, who issued it and when it expires.
• Make switching cheap. Issue certificates automatically (ACME), so that moving to another certificate authority takes minutes, not a week of emails.
• Your trust lists are software too. Java, Python, Node.js and container base images each carry their own copy of “who to trust”. Keep them updated like any other dependency.
• Watch the public record. Certificate Transparency is how the world proved nobody was harmed this time. The same logs can tell you, for free, the moment someone gets a certificate for your domain.

This article reflects public information as of 23 October 2026. Details may change as vendors publish further updates. Always follow your certificate authority’s and browser vendors’ official guidance.

Sources

1. eMudhra: Certificate security incident
2. Google: Protecting Chrome and Android users from compromised eMudhra intermediate CA certificates
3. Mozilla: Protecting Firefox users following the compromise of eMudhra intermediate certificates
4. The Hacker News: Eight eMudhra CA keys compromised
5. Node.js: October 2026 security releases
6. CERT-In advisory CIAD-2026-0050
7. Business Today: eMudhra to exit global SSL/TLS certificate business

All insights→