October 29, 2026 13 min to read

The eMudhra CA Key Compromise: What It Means for Your Business

Your browser was fixed in two hours. Your servers, scripts and devices may still trust forged certificates

Every time your laptop, your payment gateway integration or your accounting app connects to a server over HTTPS, it asks one question: is this certificate signed by someone I trust? That trust is outsourced to a few hundred certificate authorities (CAs). This month one of them, India’s eMudhra, turned out to have published eight intermediate CA certificates whose private keys were so weak that one of them was literally the number 4.

Anyone holding those keys could have issued a certificate for any website (your bank, your payment provider, your Microsoft 365 tenant) that a large share of software would have accepted. Browser makers fixed it within hours. The harder problem is everything that isn’t a browser: servers, scripts, Java applications, containers, routers and printers. That is where most businesses still have homework to do.

TL;DR / Key takeaways

• What happened: Private keys for eight eMudhra intermediate CAs (six for websites, two for code signing) were generated with almost no randomness and could be computed from the public certificates in under a second. They were created in April 2025, so they were effectively public for about 17 months.
• Browsers are protected: Chrome, Firefox, Apple, Microsoft and Android blocked the certificates between 17 and 20 October 2026. Chrome found no website certificates issued from these CAs in public Certificate Transparency logs.
• Non-browser software is the risk: Many apps, scripts, Java runtimes, containers and devices don’t check revocation or Certificate Transparency. They stay exposed until their own trust store is updated.
• Possible breakage: Some vendors removed the eMudhra root entirely, and eMudhra announced on 22 October that it is leaving the global SSL/TLS business. If your sites use eMudhra TLS certificates, replace them now.
• Do this week: Update OS trust stores and runtimes, rebuild container images, test your applications against the public test hosts, and replace any eMudhra-issued TLS certificates.

What happened, in plain language

A certificate authority’s job is to keep a secret: its private key. Whoever has that key can create certificates that software trusts. In this case, eMudhra didn’t lose its keys to hackers. The keys were weak from the moment they were made.

According to eMudhra, a bug in the script used during its 30 April 2025 key-generation ceremony created a second, weak key pair on its hardware security module, and a human error meant those weak keys were the ones used. The resulting certificates were cross-signed by Sectigo’s legacy AAA Certificate Services root in May 2025, which widened the set of software that would trust them.

How weak? Researcher Scott Helme explains that a P-384 private key should be a random 384-bit number. These keys were single-byte values such as 4, 56 and 115. Recovering one means trying, at most, 255 possibilities. He recovered all of them in under a second. Mozilla independently recovered the keys within two hours of the report.

The affected intermediates are:

• TLS (website) CAs: EM DV TLS CA - G3B / G3C, EM OV TLS CA - G3B / G3C, EM EV TLS CA - G3B / G3C
• Code-signing CAs: EM OV CS CA - G3B / G3C

Timeline

Was anyone actually attacked?

As far as public evidence goes, no confirmed malicious use has been reported. Google says no TLS certificates chaining to these CAs were logged to Certificate Transparency before the block. Cloudflare found no active exploitation against its services. CERT-In said on 21 October that public disclosures did not establish confirmed malicious use, and MeitY described the impact on Indian websites as “very limited and for a very short interval.”

But “no evidence” is not “no risk”. Helme makes the important point: Certificate Transparency detects mis-issuance, it doesn’t prevent it. A forged certificate used in a targeted attack against software that doesn’t check CT would never need to be logged publicly. With a 17-month window, nobody can prove it didn’t happen.

Why browsers are fine but your business may not be

Browsers have fast, centralised kill switches (Chrome’s CRLSets, Firefox’s OneCRL) and they enforce Certificate Transparency. Most other software has neither. As Helme puts it, most non-browser TLS clients trust whatever CA bundle is on disk, skip revocation checks and skip CT.

In his testing, curl, Python and Node.js on Linux and macOS accepted a forged certificate for api.stripe.com chained to one of the compromised intermediates. On Windows, CryptoAPI accepted it unless revocation checking was turned on. Azul notes that Java runtimes “do not check certificate revocation by default”.

Translate that into business systems and the exposure looks like this:

• Server-to-server API calls: payment gateways, SMS and email APIs, ERP and courier integrations, webhooks.
• CI/CD pipelines and installers: build servers pulling packages, curl | bash installers, update agents.
• Java applications: line-of-business apps, middleware and many on-premises enterprise products ship their own Java runtime.
• Containers: an image built before the fix keeps the old trust store even if the host is patched.
• Devices you can’t easily update: routers, firewalls, printers, POS terminals, IoT. Helme calls this the hardest problem, because unpatched devices may keep trusting these certificates until they expire in July 2039.
• Code signing: anything that verifies software signatures chaining to eMudhra’s code-signing root needs separate review.

An attacker would still need to be in a position to intercept traffic (a compromised network, a malicious Wi-Fi hotspot, a hijacked DNS record or upstream provider). That is a real bar, but it’s exactly the kind of position state-sponsored groups and serious criminals routinely obtain.

Am I affected?

You have work to do if any of these are true:

1. You run Linux servers, containers or developer machines whose ca-certificates package, Python certifi, Node.js, Go or Java runtime hasn’t been updated since 20 October.
2. You build and ship software (especially in Go, which embeds the check at compile time and needs a rebuild, or Electron apps).
3. You run Java applications, whether in-house or vendor-supplied, unless the JDK vendor has shipped an update.
4. You use macOS for development. Dennis Jackson’s tracking page reports no macOS patch is listed yet and that built-in tools such as curl, git and Python still trust the certificates.
5. Your websites or APIs use certificates issued by eMudhra/emSign. Chrome removed emSign ECC Root CA - G3 and other platforms have removed roots, so visitors may start seeing errors. eMudhra says it will replace affected certificates free of charge.
6. You rely on network appliances, IoT or embedded devices that make outbound HTTPS calls and rarely get firmware updates.

Quick check for your own websites (who issued my certificate?):

~|#| Replace example.com with your domain. Look for "eMudhra" or "emSign" in the issuer.
openssl s_client ~|-|connect example.com:443 ~|-|servername example.com ~|<|/dev/null 2>/dev/null \
  | openssl x509 ~|-|noout ~|-|issuer ~|-|enddate

Quick check for your software (does this client still trust the bad chain?). The independent disclosure site publishes test hosts. Run this from the real environment (the server, container or CI runner), not your laptop:

~|#| A certificate ERROR is good: the client rejects the compromised chain.
~|#| A successful connection means this environment still trusts it.
curl ~|-|sS ~|-|o /dev/null https://dv~|-|g3b~|-|emudhra.we~|-|have~|-|a~|-|problem.com/ && echo "STILL TRUSTS (fix needed)"
curl ~|-|sS ~|-|o /dev/null https://dv~|-|g3b~|-|aaa~|-|emudhra.we~|-|have~|-|a~|-|problem.com/ && echo "STILL TRUSTS via AAA cross~|-|sign (fix needed)"
~|#| Same test from Python, which uses certifi in many apps:
python3 ~|-|c "import urllib.request as u; u.urlopen('https://dv~|-|g3b~|-|emudhra.we~|-|have~|-|a~|-|problem.com/'); print('STILL TRUSTS (fix needed)')"

The site also offers noct variants that serve certificates never logged to Certificate Transparency. If those connect successfully, the client trusts the chain and doesn’t enforce CT.

Inventory checks on Linux and Windows:

~|#| Linux: should return 0 after the ca~|-|certificates update
grep ~|-|c "emSign" /etc/ssl/certs/ca~|-|certificates.crt

~|#| Python: certifi must be 2026.10.19 or later
python3 ~|-|c "import certifi, importlib.metadata as m; print(m.version('certifi'), certifi.where())"

~|#| Find bundled CA files hiding inside apps and images
find / ~|-|xdev \( ~|-|name "cacert.pem" ~|-|o ~|-|name "ca~|-|bundle.crt" ~|-|o ~|-|name "cacerts" \) 2>/dev/null

~|#| Windows: list eMudhra/emSign roots and intermediates present in machine stores
Get~|-|ChildItem Cert:\LocalMachine\Root, Cert:\LocalMachine\CA |
  Where~|-|Object { $_.Subject ~|-|match "emSign|eMudhra|EM (DV|OV|EV) TLS|EM OV CS" } |
  Select~|-|Object PSParentPath, Subject, Thumbprint, NotAfter

Fixed versions to look for

Some projects were still pending at the time of writing, including OpenJDK upstream and certbot, according to the community tracker. Check it for your stack before assuming you’re covered.

A prioritised action plan

Immediately (today)

• Check who issues your certificates. If any public site or API uses an eMudhra/emSign TLS certificate, request a replacement from eMudhra or buy one from another CA and install it now. Chrome’s guidance is to “immediately acquire and install a new TLS certificate from another PKI hierarchy”.
• Update OS trust stores on internet-facing servers and anything that calls payment, banking or identity APIs (apt-get install --only-upgrade ca-certificates, apk upgrade ca-certificates, vendor equivalents).
• Tell your team not to click through certificate warnings and never to “fix” a TLS error by disabling verification. Cloudflare specifically warns against this.

This week

• Upgrade runtimes and libraries that carry their own trust store: Node.js, Go (and rebuild), Python certifi, Java runtimes, Electron apps, Composer.
• Rebuild container images from patched base images and redeploy. A patched host doesn’t fix an old image.
• Run the test-host checks from each production environment, CI runner and developer platform, and record the results.
• Ask your vendors in writing: for every business-critical application, appliance and SaaS integration, ask whether it is affected and when it will be fixed. Java-based products and network appliances first.
• Review TLS inspection, proxy and endpoint logs for certificates issued by the eight intermediates, prioritising systems that send credentials or payment data.

Longer term

• Treat trust stores like dependencies. Inventory them, prefer the operating system store over bundled PEM files, and flag vendored cacert.pem files in code review and SBOMs.
• Build certificate agility. Know every certificate you own, who issued it and when it expires, and automate renewal (ACME) so switching CA is a configuration change, not a project.
• Plan for devices that never update. Segment them, restrict their outbound destinations, and add trust-store patching to procurement requirements.
• Turn on revocation checking where your platforms support it for high-value outbound connections.

OffensioX perspective

The striking thing about this incident isn’t the bug. It’s how unevenly the internet recovered. Browser vendors pushed protection to billions of users in a few hours, without a restart. Meanwhile, the software that actually moves money and data between businesses (API clients, Java middleware, build pipelines, embedded devices) is still being patched one package at a time, and some of it never will be.

For businesses in Pakistan and across South Asia, there are two practical lessons. First, the “trust layer” is part of your supply chain, just like npm packages or a third-party plugin, and most organisations have never inventoried it. Second, regional providers are increasingly part of the global trust fabric, so an incident at one vendor ripples everywhere at once. It’s also worth noting that the problem was found by outside researchers, not by audits: eMudhra says its roots and issuing CAs passed independent audits two years running. Compliance checkboxes are not the same as adversarial testing.

If you want a clear picture of which of your applications, servers and integrations would accept a forged certificate, OffensioX can help through penetration testing and security assessments that test what your systems actually trust, not just what the configuration says.

References

• Mozilla Security Blog: Protecting Firefox users following the compromise of eMudhra intermediate certificates
• Google: Protecting Chrome and Android users from compromised eMudhra intermediate CA certificates
• Scott Helme: Eight bits of trust: eMudhra’s CA keys cracked in milliseconds
• eMudhra Intermediate CA Compromise: test hosts and affected software tracker
• eMudhra: eMudhra to exit global SSL/TLS certificate business
• Cloudflare: eMudhra certificate compromise
• Azul: Statement on the eMudhra intermediate CA certificates compromise
• Endor Labs: eMudhra CA compromise: the trust stores you patched and the ones you didn’t know you had
• The Hacker News: Eight eMudhra CA keys compromised, triggering emergency fixes across browsers and software
• Hackread: eMudhra to exit SSL/TLS market after 8 CA keys found easily guessable
• Business Today: MeitY says impact on Indian sites “very limited”
• Go issue #82345
• Red Hat RHSB-2026-012