eMudhra CA Compromise: Using Backup Snapshots to Find Systems That Still Trust the Compromised CAs

Detect, verify and contain public-CA trust exposure across your protected estate, without touching production.

By: Gyan Prakash and Digvijay Goutam

Executive summary

Key risk factors

Technical details

Recommended Actions for Cohesity Data Cloud Administrators
1. Inventory Trust Stores Across Protected Data
2. Confirm Exposure by Certificate Fingerprint
3. Protect Your Restore Path
4. Validate Immutability and Admin Controls
5. Rehearse Clean Recovery and Brief Your Counterparts

Detection Details: Locating and Verifying Compromised CAs
Reading the Results
Validating the Detection in Your Environment
Limitations

Conclusion
References

Executive Summary

Cohesity is publishing this advisory in response to the compromise of eight eMudhra intermediate certificate authority (CA) private keys. The keys were generated incorrectly and can be recovered from the certificates themselves, which means an attacker can mint trusted TLS certificates for any hostname and impersonate websites and cloud APIs. Major browsers blocked the affected CAs within days of disclosure. Servers, runtimes and appliances do not fix themselves. Each one keeps trusting the compromised CAs until an administrator updates its operating-system and language trust stores. This is a public-CA trust problem, so it reaches far beyond any single application.

The affected CAs, their fingerprints and vendor remediation status are tracked at the industry incident site, https://emudhra.we-have-a-problem.com/.

Your backups are not at risk from this incident, but they are one of the best tools you have for handling it. The compromised CAs live in trust stores scattered across the operating system, Java, Python, Go and Node.js on every protected web service, and many of those systems are not on any patching team's list. Backup snapshots give administrators a point-in-time view of every protected system without touching production. They show which systems still trust the compromised CAs, when that trust first appeared, and which recovery points would bring an exposed trust store back online after a restore.

Key Risk Factors

The eMudhra compromise behaves differently from a typical application vulnerability. The points below explain why it is easy to miss and why it can still affect systems you believe are fully patched.

The weakness sits beneath the application. Any web service that makes outbound TLS is exposed regardless of language or framework, so a hardened, fully patched application is still at risk if its host trust store trusts a compromised CA. The application tells you nothing; the evidence is the trust-store file itself, which every backup already holds.
Non-browser clients are the residual risk. Browsers were protected quickly through revocation feeds, but servers, scripts, connectors and appliances trust whatever the OS and runtime trust store says, and stay exposed until someone updates it. Those server workloads are exactly what Cohesity protects, so their trust stores already sit in your snapshots, ready to check in the backup copy instead of on the live host.
The impact is interception and impersonation. An attacker on the network path can impersonate cloud and SaaS endpoints such as Microsoft 365, Salesforce, Azure, Amazon S3 and Google Workspace, capturing data and credentials in transit. That urgency calls for finding every exposed system quickly and across the whole estate, which a scan of backup copies does from one place, with no production access and no downtime.
Trust is scattered and easy to miss. The OS bundle, Java cacerts, Python certifi, Go and Node each carry their own copy of the trusted roots, and forgotten appliances and container images ship their own. No single console in production lists them all, but a backup copy holds every one of those files for every protected system, so the backup is the one place you can inventory them all.
Restores can reintroduce the risk. A recovery point taken before remediation restores a trust store that still trusts the compromised CAs, quietly undoing the fix.

Technical Details

The incident at a glance:

Item	Detail
Compromised assets	Eight eMudhra intermediate CA private keys, recoverable from the public certificates
Root cause	Flawed key generation; the private keys can be derived from the certificates themselves
Realistic attack	Mint trusted TLS certificates for any hostname; man-in-the-middle and impersonation of HTTPS endpoints
Who is still exposed	Non-browser clients that trust the affected CAs through OS or language runtime trust stores
Browser status	Blocked by major browsers within days of disclosure
Relevant fixes	OS ca-certificates updates; Go 1.26.10 / 1.27.3 (CVE-2026-111943); Python certifi 2026.10.19; curl CA extract update

Because the exposure lives in trust stores rather than in application code, the practical questions for every administrator are the same: which protected systems still trust the compromised CAs, and which recovery points would bring that trust back. Both can be answered from backup snapshots.

Recommended Actions for Cohesity Data Cloud Administrators

The eMudhra exposure is remediable, but remediation depends on knowing where the compromised CAs are trusted. Recovery points held in Cohesity Data Cloud may restore exposed systems, so the actions below are ordered by impact.

1. Inventory Trust Stores Across Protected Data

Use Cohesity Data Cloud indexing and search to locate the OS and runtime trust stores across protected VMs, physical servers and NAS data that host web services, including web servers, application tiers, containers and vendor appliances that ship their own trust store.
Rank by exposure: internet-facing systems and those with active cloud or SaaS connectors first, then internal web applications, then everything else.
Record the owner and remediation plan for each system and share the list with web, application and SOC owners so everyone works from the same priorities.

2. Confirm Exposure by Certificate Fingerprint

Extract only the trust-store files from each snapshot and compare every certificate's SHA-256 fingerprint against the published list of compromised CAs. A fingerprint match is a confirmed exposure.
Do not rely on certificate names alone. One of the affected roots is a common, legitimately trusted CA, so a name match is not evidence (see Detection Details).

3. Protect Your Restore Path

After the OS and runtime trust stores are updated on production, remember that restoring from a snapshot taken before remediation brings back a trust store that still trusts the compromised CAs.
Restore into an isolated network, update trust, validate, then reconnect to production, and update your restore runbooks accordingly.

4. Validate Immutability and Admin Controls

Confirm DataLock (WORM) is enabled on Protection Groups covering web and application tiers, with retention longer than your detection-to-decision window.
Verify Quorum is configured for destructive operations so a single compromised administrator cannot shorten retention or delete snapshots.
If you use Cohesity FortKnox, confirm recent vault copies are current, and review Helios and cluster administrator accounts for MFA, least privilege and separation of duties.

5. Rehearse Clean Recovery and Brief Your Counterparts

Run a clean-room recovery drill for a web tier: restore to an isolated segment, update the trust store, validate TLS to your key endpoints, and only then reconnect. Measure the time it takes and brief your security and application owners.

Detection Details: Locating and Verifying Compromised CAs

Detection runs in two stages against protected data, with no need to log in to each host. First locate the trust stores and the systems that may be affected. Then verify each candidate by certificate fingerprint, which is the only authoritative test. The stages can be run across current snapshots and older recovery points, so you also learn when exposure first appeared and can prove it is gone after remediation.

What to look for

Confirm every finding against the published SHA-256 fingerprints of the compromised certificates. The distinctive root names are useful only to locate candidates quickly.

Compromised root CA (Subject CN)	Confirm by
emSign Root TLS CA - G3	SHA-256 fingerprint
emSign Root CS CA - G3	SHA-256 fingerprint
emSign ECC Root CA - G3	SHA-256 fingerprint
AAA Certificate Services	SHA-256 only (common root; a name match is not evidence)

Eight compromised intermediate certificates are also in scope and are matched the same way, by SHA-256 fingerprint. Load the fingerprints for all roots and intermediates into the verification step below.

Where trust stores live inside a backup

Layer	Path inside the backup	Note
OS (RHEL family)	/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem	Primary: the compiled bundle clients read
	/etc/pki/ca-trust/source/anchors/	Secondary: locally added trust only
OS (Debian/Ubuntu)	/etc/ssl/certs/ca-certificates.crt	Compiled bundle
OS (SUSE)	/var/lib/ca-certificates/ca-bundle.pem	Compiled bundle
Java	$JAVA_HOME/lib/security/cacerts; .jks; .p12	Binary keystore
Python	.../site-packages/certifi/cacert.pem	Per environment or container
Go / Node.js	OS bundle; app-embedded PEM; Node built-in set	Carried by the runtime
curl / app	/etc/pki/tls/certs/ca-bundle.crt	Usually a symlink to the OS bundle
Windows	Machine Root store (registry); JRE/JDK cacerts	Registry hive, not a flat file

Scope: what counts, and what does not

In scope: outbound one-way TLS from web services and connectors (Microsoft 365, Salesforce, Azure, Amazon S3, Google Workspace and similar).

Out of scope: mutual-TLS agent paths, connectors configured to skip verification, and customer-supplied private CAs. These are not affected by this public-CA incident.

The detection scripts

Each listing is self-contained. Run them against the trust-store files extracted from a snapshot.

Listing 1. Build the known-bad indicator set

# From the published incident data, build one lowercase SHA-256 list
# of every compromised root and intermediate certificate.
jq -r '.[].sha256' roots.json impacted-intermediates.json \
| tr 'A-F' 'a-f' | tr -d ': ' | sort -u > badhashes.txt

Listing 2. Verify PEM trust bundles (OS, Python certifi, curl)

# Split each bundle into individual certificates, then compare
# every fingerprint against the known-bad list.
for f in tls-ca-bundle.pem ca-certificates.crt \
certifi/cacert.pem ca-bundle.crt; do
  [ -f "$f" ] || continue
  awk '/BEGIN CERT/{n++} {print > ("cert_" n ".pem")}' "$f"
  for c in cert_*.pem; do
  fp=$(openssl x509 -in "$c" -noout -fingerprint -sha256 \
| sed 's/.*=//; s/://g' | tr 'A-F' 'a-f')
  grep -qx "$fp" badhashes.txt \
  && echo "EXPOSED: compromised CA found in $f"
done; rm -f cert_*.pem
done

Listing 3. Verify Java keystores (cacerts, .jks, .p12)

# Enumerate every keystore entry's SHA-256 and compare.
keytool -list -keystore cacerts -storepass changeit 2>/dev/null \
  | grep -i 'SHA256:' | sed 's/.*SHA256: //; s/://g' | tr 'A-F' 'a-f' \
  | while read -r fp; do
  grep -qx "$fp" badhashes.txt \
  && echo "EXPOSED: compromised CA found in cacerts"
  done

Listing 4. Optional: locate candidates fast with a Threat Library YARA rule

Use this only as a quick locator inside a Cohesity Data Cloud custom scan, then confirm every hit with Listings 2 and 3. It matches the distinctive emSign names and deliberately does not match the common root by name.

rule eMudhra_Compromised_CA_Candidate
{
  meta:
  description = "Trust store may carry a compromised emSign root;"
  confirm_by = "SHA-256 fingerprint (Listings 2 and 3)"
  author      = "Cohesity"
  strings:
  $cn1 = "emSign Root TLS CA - G3" ascii nocase
  $cn2 = "emSign Root CS CA - G3" ascii nocase
  $cn3 = "emSign ECC Root CA - G3" ascii nocase
  $al1 = "emsignroottlscag3" ascii
  $al2 = "emsignrootcscag3" ascii
  $al3 = "emsigneccrootcag3" ascii
  $pem = "-----BEGIN CERTIFICATE-----" ascii
  $jks = { FE ED FE ED }
  condition:
  (any of ($cn*) or any of ($al*)) and ($pem or $jks at 0)
}

Reading the Results

Result	What it means
Fingerprint match in a trust store	Confirmed exposure. This protected system still trusts a compromised CA. Remediate, then re-verify on the next snapshot.
emSign name match, no fingerprint match	Benign certificate that shares a name. Expected for AAA Certificate Services. No action.
No trust-store file on a system you expect	The system may not have been scanned, or trust lives elsewhere (Windows registry hive, an app-private path). Investigate.
Match only in an older snapshot	Shows when exposure began, or confirms remediation has since removed the compromised CA.

Validating the Detection in Your Environment

Before relying on the results to make decisions, confirm the method against trust stores from your own estate. Take one known-exposed trust store (captured before remediation) and one known-good trust store (after the OS or runtime update), and run Listings 2 and 3 against both. The exposed store should report a fingerprint match and the good store should report none. Repeat for each trust-store type you operate, including the OS bundle, Java cacerts and Python certifi, so the detection reflects the builds actually present in your environment.

Limitations

Trust is not the same as exploitation. A compromised root in a trust store means the host would trust a forged certificate, not that an attacker is on the network path. Prioritise systems that make outbound public HTTPS over untrusted networks.
Confirm by fingerprint, never by name. The common root and the compromised intermediates must be confirmed by SHA-256. Name matching is only a first-pass locator.
Windows trust lives in the registry. The Windows machine trust store is a registry hive, not a flat file. Cover it through Java and application keystores, exported certificates, or a registry parse on mount.
Password-protected keystores. A keystore with a non-default password cannot be enumerated from backup without that password. Flag these for owner-side verification.
Snapshots are point-in-time. A system remediated after the snapshot will still be flagged until the next backup, and a trust store updated without restarting long-running services may still be trusted in memory. Pair the scan with confirmation from the system owner.

Conclusion

The eMudhra compromise shows how trust in a single shared public CA can expose a large share of an organisation's outbound connections at once, including systems running well-written, fully patched application code. Remediation is a matter of updating trust stores, and it begins with an accurate inventory, which backup administrators are uniquely placed to build. Cohesity Data Cloud holds point-in-time copies of the systems most likely to make outbound TLS and can find and verify exposed trust stores without touching production. Backups are the last line of defense, and the techniques in this advisory help ensure that an exposed trust store is not restored back into production.

References

eMudhra / emSign CA compromise, industry incident site (affected CAs, fingerprints, vendor status): https://emudhra.we-have-a-problem.com/
Mozilla Security Blog, OneCRL distrust of the affected eMudhra / emSign CAs (2026-10-20): https://blog.mozilla.org/security/
CVE-2026-111943, Go crypto/x509 denylist for the compromised intermediates, fixed in Go 1.26.10 and 1.27.3: https://www.cve.org/CVERecord?id=CVE-2026-111943
CVE-2026-113470 / Mozilla MFSA, Firefox OneCRL block-list update: https://www.mozilla.org/en-US/security/advisories/
Red Hat RHSA, ca-certificates update distrusting the affected roots and intermediates: https://access.redhat.com/security/security-updates/
Python certifi, patched CA bundle, release 2026.10.19: https://pypi.org/project/certifi/
curl CA extract (caextract), updated Mozilla trust store (2026-10-20): https://curl.se/docs/caextract.html
Microsoft, Apple and Google, platform revocation and distrust actions, October 2026: https://emudhra.we-have-a-problem.com/
Cohesity REDLab advisories: https://www.cohesity.com/platform/redlab/advisories

The next big leap is almost here