The eMudhra CA compromise: Our response and how to check your own systems

Why this matters to an endpoint security company

As an endpoint security company, deciding who and what to trust is part of our daily work. When eMudhra's intermediate CAs were compromised, we audited our own systems quickly.

This post covers what happened, why browsers were protected within hours to days while other software was not, how we reviewed the systems behind our own services, and six practical tips for checking yours.

TL;DR

• Eight intermediate certificate authorities run by eMudhra had private keys that anyone could recover. Depending on the key, whoever holds one can issue a certificate for any website or sign software that unpatched systems will trust.
• Chrome and Firefox were protected within hours without any update, and Safari and Edge within three days. Servers, containers, CLI tools, language runtimes and appliances that keep their own list of trusted CAs were not protected automatically, and many still need updates.
• None of our certificates were issued by eMudhra. We reviewed the outbound side of our environment, the trust stores our own services rely on, and closed the gap there.
• Below are six practical tips to check your systems and fix them without breaking your own custom CA lists.

What happened

On October 17, 2026, a researcher reported that the private keys of eight eMudhra intermediate CAs (six for TLS, two for code signing) could be computed from their public certificates. The keys were numbers below 256, so all eight can be found by trying 256 candidates. The intermediates were created in April 2025, so the keys were exposed for about 18 months. BleepingComputer has a good overview of the incident and the browser response.

The industry response was quick:

No certificate from the six TLS CAs was logged to public Certificate Transparency (CT) logs before browsers blocked them, and eMudhra says it knows of no exploitation before disclosure. After disclosure, over 100,000 certificates signed with the keys appeared in CT logs, according to a count posted on Mozilla's incident record. Nearly all were proofs of concept for google.com, issued through the Sectigo cross-sign path described below, which shows how easy the keys are to use. CT only shows certificates someone chose to log, so past misuse can't be ruled out for clients that don't enforce CT.

Why browsers were protected quickly, and why other software needs attention

Browsers have two mechanisms most other software lacks:

• Push revocation lists (Chrome's CRLSet, Firefox's OneCRL) that update silently, without a release.
• Certificate Transparency enforcement, which rejects certificates that were never publicly logged.

Most other TLS clients have neither. They trust whatever is in their CA bundle until someone updates it. That includes the trust stores of Linux and other package-managed systems, language runtimes and package managers, container images, Java keystores, appliances and embedded devices. Many applications also ship their own bundle, separate from the operating system's, so updating the OS alone isn't enough.

One detail catches many people: the same eight keys were also cross-signed under Sectigo's old AAA Certificate Services root. Removing only the eMudhra root leaves a second path open wherever that root is still trusted.

Are you affected?

How we responded

None of our certificates were issued by eMudhra, so the root removals by Chrome and other browsers don't affect access to our services. That left the other direction to examine: the outbound connections our own systems make, which depend on the CA lists those systems trust.

We began remediation within days of the incident becoming public, and we went beyond operating system updates. We inventoried the trust stores our services use, including the ones bundled inside applications and tools, and confirmed that none of the components making outbound connections still trusts the affected roots. Depending on the component, we pointed it at the cleaned system store or removed the affected certificates directly. We then verified the result against public test endpoints that serve certificates from the compromised CAs. We have found no evidence that our services or customer data were affected.

This is the same discipline we encourage our customers to apply to their fleets: know exactly what each system trusts, change it deliberately, and verify the outcome from where the code actually runs.

Six practical tips

1. Update, then test from where the code runs. Install your OS's latest CA package, then check from the server or container itself, not from your laptop:

for h in dv-g3b-emudhra dv-g3b-aaa-emudhra; do
  curl -sS -o /dev/null "https://$h.we-have-a-problem.com/" \
    && echo "$h: STILL TRUSTED"
done

A certificate error on both is the result you want. The second host tests the Sectigo cross-sign path.

2. Don't trust a test made through a TLS-inspecting proxy or antivirus. The results then reflect the proxy's trust store, not yours, so they can look safe or vulnerable regardless of your fix.

3. The OS store is only one of several. Java keystores, language runtimes and package managers, bundled CA files inside applications and agents, and container images each keep their own list. Search your systems for CA bundles and check each one. On some systems the Java keystore isn't refreshed by the OS update at all.

4. Restart and rebuild. Most services load their trust store once at startup, so restart anything that makes outbound HTTPS calls. A running container keeps the store it was built with until you rebuild the image and redeploy it.

5. Don't overwrite a custom bundle just to fix it. If a bundle contains your private or partner CAs, replacing it with a fresh public one silently breaks those connections. Remove only the affected certificates, matched by SHA-256 fingerprint rather than name, and compare the old and new files before switching. The compromised intermediates' fingerprints are listed in the Konfirmity advisory, and the Sectigo cross-certificates' in comment 2 of Mozilla's incident record. The two roots' SHA-256 fingerprints, to compare with the output of openssl x509 -noout -fingerprint -sha256 -in cert.pem | tr -d ::

for h in dv-g3b-emudhra dv-g3b-aaa-emudhra; do
  curl -sS -o /dev/null "https://$h.we-have-a-problem.com/" \
    && echo "$h: STILL TRUSTED"
done

6. Never disable certificate verification to silence the new errors. That removes exactly the protection the update restores.

Questions about your Tether deployment?

If you'd like to talk through how this incident applies to your environment, or how Tether helps you keep device trust decisions current across your fleet, get in touch with our team.

Sources

• Community incident tracker: test sites, fixed versions, per-OS workarounds
• Google Security Blog: Protecting Chrome and Android users from compromised eMudhra intermediate CA certificates
• Mozilla Security Blog: Protecting Firefox users following the compromise of eMudhra intermediate certificates
• Rescana: eMudhra's incident updates, including its statement on exploitation
• Mozilla incident record (Bugzilla 2083449)
• oss-security announcement
• Konfirmity advisory: affected certificates and fixed versions
• The Hacker News: eMudhra exits the SSL/TLS business
• eMudhra press release, October 22, 2026
• ThePrint: Microsoft drops eMudhra certificates from Windows and Edge
• SSL.com: Chrome removing the eMudhra root
• ctlogs.dev: emSign ECC Root CA - G3 and AAA Certificate Services (root fingerprints)