eMudhra Intermediate CA Key Compromise: Interim Mitigation (v4)

Security Notices
1

eMudhra Intermediate CA Key Compromise: Interim Mitigation (v4 / Oct 28, 2026)
Updated: 10/28/26 (scripts available). 10/27/26: six roots instead of two.
Remove six root certificates from the Java trust store of each affected Ignition runtime (the Gateway, Designer, Vision Client, launchers, and Workstation):

  1. “emSign ECC Root CA - G3” (compromised intermediates chain to)
  2. “AAA Certificate Services” (compromised intermediates chain to)
  3. “emSign Root CA - G1” (eMudhra’s other roots)
  4. “emSign Root CA - G2” (eMudhra’s other roots)
  5. “emSign Root CA - C1” (eMudhra’s other roots)
  6. “emSign ECC Root CA - C3” (eMudhra’s other roots)

The first four are the roots Oracle lists at https://ops.java/emudhra; the last two are only in runtimes from older Ignition versions.

Already removed two roots? If you followed an earlier version of this post, run the Check below on each runtime you fixed, and delete each root it shows.

Scripts. Instead of the steps below, you can run our scripts for Windows, Linux and macOS. They remove the six roots from every Ignition runtime on a machine, including the runtimes a Gateway sends to Designers and Vision Clients. Download them and read how to run them at GitHub - inductiveautomation/ignition-emudhra-mitigation: Scripts and instructions that remove the eMudhra and AAA Certificate Services roots from the Java runtimes bundled with Ignition. · GitHub . The Windows script is signed by Inductive Automation, LLC.

Scope. This affects outbound HTTPS connections an Ignition component makes that an attacker on the network path can intercept: Gateway Network peers, identity providers, mail servers, web APIs called from scripts. Prioritize Gateways and clients that reach HTTPS services across the internet or untrusted networks.

Not affected: inbound connections to the Gateway; Gateway Network connections using two way authentication with an approved only policy (the default); and Perspective sessions in a browser, which use the browser’s trust store.

Side effects. Removing these roots also stops the runtime from trusting any server whose certificate chains only to one of them, including any certificate eMudhra issued under its emSign roots. Before you remove them, check the HTTPS services your Gateways and clients connect to, and watch for certificate errors after the restart. To revert, restore the backup.

Steps. Back up the runtime’s lib/security/cacerts file, run the Check below, run the four keytool deletes with that runtime's own keytool (store password changeit), run the Check again and delete any root it still shows, then restart the Gateway service and relaunch clients.

Back up: in each runtime folder, copy lib/security/cacerts to cacerts.orig.

Remove the roots (must run on the correct JRE):
Windows (PowerShell):

& "<runtime>\bin\keytool.exe" -delete -cacerts -alias "emsignrootcag1 [jdk]" -storepass changeit
& "<runtime>\bin\keytool.exe" -delete -cacerts -alias "emsignrootcag2 [jdk]" -storepass changeit
& "<runtime>\bin\keytool.exe" -delete -cacerts -alias "emsigneccrootcag3 [jdk]" -storepass changeit
& "<runtime>\bin\keytool.exe" -delete -cacerts -alias "comodoaaaca [jdk]" -storepass changeit

Linux and macOS:

"<runtime>/bin/keytool" -delete -cacerts -alias "emsignrootcag1 [jdk]" -storepass changeit
"<runtime>/bin/keytool" -delete -cacerts -alias "emsignrootcag2 [jdk]" -storepass changeit
"<runtime>/bin/keytool" -delete -cacerts -alias "emsigneccrootcag3 [jdk]" -storepass changeit
"<runtime>/bin/keytool" -delete -cacerts -alias "comodoaaaca [jdk]" -storepass changeit

Note: <runtime> is the runtime folder you are patching. Always give keytool's full path, even from inside the runtime's bin folder: a bare keytool runs whichever Java is on the system path, and -cacerts then changes that Java's trust store instead of Ignition's. Each runtime's keytool is in its bin folder:

Gateway: C:\Program Files\Inductive Automation\Ignition\lib\runtime\jre-win on Windows, /usr/local/bin/ignition/lib/runtime/jre-* on Linux, /usr/local/ignition/lib/runtime/jre-mac on macOS.

Designer and Vision Client: one runtime per Gateway version for each user, in C:\Users\<user>\.ignition\cache\resources\runtimes\<version> on Windows and ~/.ignition/cache/resources/runtimes/<version> on Linux and macOS.

Launchers and Workstation: the jre folder in the install folder on Windows, <Launcher name>.app/Contents/Resources/runtime on macOS, and the runtime folder you extracted the launcher into on Linux.

On Linux and macOS, keytool isn't always marked executable: it never is in a Designer or Vision Client runtime, and on some Linux gateways it isn't either. If running it reports "Permission denied", run it through that runtime's java with the same options instead, for example:
"<runtime>/bin/java" -m java.base/sun.security.tools.keytool.Main -delete -cacerts -alias "emsigneccrootcag3 [jdk]" -storepass changeit

Or make it executable first: chmod +x "<runtime>/bin/keytool"

Docker. Changes made inside a container are lost when it is recreated, for example on an upgrade or a configuration change. Run these steps again after each recreate, or mount a copy of cacerts with the roots removed over /usr/local/bin/ignition/lib/runtime/jre/lib/security/cacerts.

Check: run these before and after the deletes. They show each of the six roots still in the runtime, with its alias name. Before, they show four in current runtimes and five or six in older ones; if they show nothing, that runtime is already fixed. Afterward, they show nothing. If one is still shown, as can happen in older runtimes, which store some of these roots under other names, delete it by that name the same way and run the Check again.

Windows (PowerShell):

& "<runtime>\bin\keytool.exe" -list -v -cacerts -storepass changeit | Select-String "Owner: CN=(emSign Root CA - (G1|G2|C1)|emSign ECC Root CA - (G3|C3)|AAA Certificate Services)," -Context 5,0

Linux and macOS:

"<runtime>/bin/keytool" -list -v -cacerts -storepass changeit | grep -B 5 -E "Owner: CN=(emSign Root CA - (G1|G2|C1)|emSign ECC Root CA - (G3|C3)|AAA Certificate Services)," | grep "Alias name"

To Undo: copy cacerts.orig back over cacerts and restart the Gateway or relaunch the client.

When to repeat. Upgrading the Gateway or a launcher replaces its runtime, so repeat these steps afterward. A patched Gateway still sends unpatched runtimes to Designers and Vision Clients, so also repeat them on a workstation whenever it downloads a new runtime: for a new user, after the cache is cleared, or after a Gateway upgrade.

What comes next. Upcoming 8.1 and 8.3 maintenance releases will bundle a runtime with these roots removed.

9 Likes
3

None of my linux gateways (so far) have had keytool marked executable. I found it easiest to just run chmod +x bin/keytool instead of the expanded form shown for the Designer and for Vision.

This the linux script I've been using, fwiw. (Note the alternate install folder I prefer.)

cd /usr/share/ignition/lib/runtime/jre-nix || exit
chmod +x bin/keytool
bin/keytool -delete -cacerts -alias "emsigneccrootcag3 [jdk]" -storepass changeit
bin/keytool -delete -cacerts -alias "comodoaaaca [jdk]" -storepass changeit
bin/keytool -list -v -cacerts -storepass changeit | grep -E "86:A1:EC:BA:08:9C:4A:8D|D7:A7:A0:FB:5D:7E:27:31"

A relative path to the keytool is fine as long as there's at least one slash in it, to exclude a PATH search.

3 Likes
4

@pturmel - thank you very much! Guidance updated.

We also added a test before and after, with the understanding that a passed test before means that no action is needed.

5

After the fix, how do we validate the Twilio module vulnerability is mitigated?

Thank you.

6

Did you post this to the right thread? Can you give some more details about what you're asking?

7

@Kevin.Herron Yes, correct thread. Our cyber team said the vulnerability exist for anything that transmits through the Internet, like Twilio alarm notifications and Slack webhooks.

The pic is how we test that fix removed the CA work. Our cyber person isn't sure if the fix also applies to the Twilio module.

image
image1317×1243 162 KB

8

Delete the two root certificates from your Ignition Gateway's root key store, restart it, and you'll be covered for all HTTPS connections that originate from the Gateway, not just ones from the Twilio module.

1 Like
9

Updating base post to V3 / Oct 27th Guidance. Below is the v2 / Oct 26th for reference:

10

Trust center post (10/28/26).

eMudhra Intermediate CA Key Compromise: Mitigation Scripts Available**

Scripts that remove the eMudhra and AAA Certificate Services roots from every Java runtime bundled with Ignition (Gateway, Designer, Vision Client, launchers, Workstation) are now available at github.com/inductiveautomation/ignition-emudhra-mitigation. The v2.0.0 release includes a Windows PowerShell script signed by Inductive Automation, LLC, a Linux/macOS script, and SHA-256 checksums. This follows Oracle's guidance at ops.java/emudhra.

Run the script on every Gateway, and on every workstation that runs a launcher or Workstation, then restart the Gateway and relaunch clients. Removing these roots also stops trust in any server whose certificate chains only to one of them, including any eMudhra issued, so check your outbound HTTPS dependencies first. A backup is kept for rollback.

Upcoming 8.1 and 8.3 maintenance releases will bundle a runtime with the fix. Discussion and updates: Ignition Security Notices forum. Questions: ignition-security@inductiveautomation.com.

We have no indication that Ignition installations have been targeted.