eMudhra Certificate Authority Compromise: CData Java Products Notice

Action recommended: compromised eMudhra certificate authorities

On October 20, 2026, it was disclosed that the private keys of eight intermediate certificate authorities operated by eMudhra were compromised. Browsers and operating systems have already blocked them. The Java editions of CData products use the trust store of their Java runtime, not the operating system's, so OS updates do not protect them.

Affected products

This applies to customers running the Java edition of these products. If you run the .NET edition, you can ignore this notice.

• CData API Server
• CData Arc (ArcESB)
• CData Connect (On-prem)
• CData Sync

An attacker would need to intercept your product's network traffic to exploit this. The risk is low, but we recommend applying the steps below. The next release of each product includes this fix, so if you upgrade to it you do not need to do anything else. Your own Java installation is not changed by an upgrade; see the section on your own Java installation below.

Arc Cloud and Sync Cloud customers: no action is needed. CData is updating all Arc Cloud and Sync Cloud instances.

Which Java runtime does your product use?

The steps below patch the trust store of the Java runtime that your product actually runs on, so start by confirming which one that is.

• If you start the product through its service (Windows) or the service script installed with the Linux tarball, it uses the bundled runtime under <install dir>/jre/<jdk folder>. Follow the Windows or Linux steps below.
• If you start the product yourself with a command such as java -jar arc.jar, it uses whichever Java is first on your PATH or set in JAVA_HOME, not the bundled runtime. Patch that Java installation instead. See Running on your own Java installation below.

Workaround without upgrading

The steps below remove two root certificates, "emSign ECC Root CA - G3" and "AAA Certificate Services", from the trust store of the Java runtime that runs your product. Your installation may contain only one of them.

Alias names for these certificates differ between Java distributions and versions. For example, Temurin 17 uses cn_emsign_ecc_root_ca__g3,o_emudhra_technologies_limited,ou_emsign_pki,c_in [jdk] while Oracle JDK 21 uses emsigneccrootcag3 [jdk]. For that reason, step 3 matches on the certificate's Owner: line, which is the same everywhere, and you read the alias from the line directly above it.

Windows

1. Open a Command Prompt as Administrator and go to the bundled Java runtime. Replace the path and folder name with the ones in your installation (CData Arc shown as an example):

   cd "C:\Program Files\CData\CData Arc\jre\jdk-17.0.20+8"

2. Back up the trust store:

   copy lib\security\cacerts lib\security\cacerts.bak

3. List every alias with the certificate it holds:

   bin\keytool -list -v -keystore lib\security\cacerts -storepass changeit | findstr /i /c:"Alias name:" /c:"Owner:"

   The output is a pair of lines per entry. Look for these two Owner: lines:

   Owner: CN=emSign ECC Root CA - G3, O=eMudhra Technologies Limited, OU=emSign PKI, C=IN
   Owner: CN=AAA Certificate Services, O=Comodo CA Limited, L=Salford, ST=Greater Manchester, C=GB

   For each one you find, the alias to delete is on the Alias name: line directly above it.

   Do not delete other emSign entries. Only "emSign ECC Root CA - G3" is affected; "emSign Root CA - C1", "emSign Root CA - C3" and "emSign Root CA - G1" are not and must stay.

4. For each alias you identified, delete the entry. Copy everything after Alias name: , including the [jdk] suffix, and keep the quotes:

   bin\keytool -delete -keystore lib\security\cacerts -storepass changeit -alias "<alias from step 3>"

5. Re-run the command in step 3. Neither of the two Owner: lines should appear any more.
6. Restart the product service.

Linux

1. Go to the bundled Java runtime inside your product installation directory:

   cd <install dir>/jre/<jdk folder>

2. Back up the trust store:

   cp lib/security/cacerts lib/security/cacerts.bak

3. Find the affected entries and the aliases that hold them:

   bin/keytool -list -v -keystore lib/security/cacerts -storepass changeit \
     | grep -E "^Alias name:|^Owner:" \
     | grep -B1 -iE "CN=emSign ECC Root CA - G3|CN=AAA Certificate Services"

   Each match prints the Alias name: line followed by its Owner: line. Delete only the aliases listed here.

   Do not delete other emSign entries. Only "emSign ECC Root CA - G3" is affected; "emSign Root CA - C1", "emSign Root CA - C3" and "emSign Root CA - G1" are not and must stay.

4. For each alias returned, delete the entry, with the alias in quotes:

   bin/keytool -delete -keystore lib/security/cacerts -storepass changeit -alias "<alias from step 3>"

5. Re-run the command in step 3. It should return nothing.
6. Restart the product service.

Running on your own Java installation, or in a Docker image you built

This also applies if you start the product with a command such as java -jar arc.jar rather than through its service, because that uses your own Java rather than the bundled runtime. Upgrading the product does not change your Java installation's trust store, so these steps are still needed after you upgrade.

Apply the same steps to that Java installation's lib/security/cacerts. Then restart the product, or rebuild the image.

As an alternative, you can leave that trust store alone and point the product at a patched copy by adding the following to the Java command line:

-Djavax.net.ssl.trustStore=<path to patched cacerts> -Djavax.net.ssl.trustStorePassword=changeit

Verifying by fingerprint

If you want to confirm an entry before deleting it, check its SHA-256 fingerprint:

keytool -list -v -keystore <cacerts> -storepass changeit -alias "<alias from step 3>"

If step 3 returns nothing, that Java runtime does not trust the affected roots, and no change is needed. On newer Java versions, keytool may print "Warning: use -cacerts option to access cacerts keystore". You can ignore it.

Removing "AAA Certificate Services" does not break connections to sites that use other Sectigo or Comodo chains. Those chain to roots that remain in the trust store.

If you have questions, contact CData Support.