Resolving Ignition Launch Client Jar Invalid on 8.1 Gateways

Mark Townsend8 min read
HMI / SCADAOther ManufacturerTroubleshooting
Licensed PE Working through this on a live machine? A Maine-licensed engineer can take it from here — included with IMD hardware, by the hour for everything else. Book an engineer

The 8.3 Designer Launcher opens your 8.3 gateway without complaint. Every 8.1.23 gateway in the list fails with Launch client jar invalid, and no Designer window appears. The cause is not a corrupt download and not an 8.3 beta bug. The newer launcher checks the code signature on the gateway's launchclient.jar by default. Gateways older than 8.1.34 serve an unsigned JAR. You fix it with one value in the launcher's JSON config, provided you edit that file correctly.

Drop the fixes that don't clear the error

Most of the time lost on this error goes into the following attempts:

  • Downgrading the Designer Launcher. Your 8.1.23 Designers open again, but you can no longer reach 8.3, which needs launcher 1.3.0 Beta-1 or later. You get one gateway back and lose the other.
  • Clearing the launcher cache. The JAR is not corrupt. It is unsigned, so a fresh download is rejected the same way. Clearing the cache does not change the result.
  • Editing the JSON while the launcher is running. The launcher writes its config when it shuts down. Your LENIENT edit gets overwritten with MODERATE the moment you close it.
  • Keeping an 8.1 launcher and an 8.3 launcher side by side. Both read and write the same designer-launcher.json on exit. Whichever launcher closed last sets the verification level for the next launch.
  • Blaming the 8.3 beta. You get the same failure with any current launcher against a gateway that predates code signing. The combination of launcher and gateway version causes it, not the release channel.
  • Emergency-upgrading every gateway. This is the correct long-term fix. It is not a same-day fix when you need a backup, a dev test, and consistency across a fleet of gateways.

Understand why the 8.3 launcher rejects the 8.1.23 JAR

Each time you launch a Designer, the launcher pulls launchclient.jar from the target gateway. Starting with 8.1.34, gateways serve that JAR code-signed. The launcher decides what to do with the signature based on the signature.verification.strength key:

  • 8.1-era launchers default to LENIENT. They open unsigned JARs from old gateways.
  • 8.3-era launchers default to MODERATE. The 8.3 User Manual states that gateways at 8.1.33 and older do not work with MODERATE.
  • LENIENT on a new launcher shows a prompt asking you to trust the unsigned launcher JAR when you connect to an older gateway. After you accept, the Designer opens.

Signature verification can also fail on a JAR that is properly signed. There are two common ways this happens:

  • Proxy tampering. A corporate firewall or man-in-the-middle proxy (SSL inspection, content scanning) modifies the JAR in transit. Any byte change invalidates the signature.
  • Blocked OCSP checks. Verification queries OCSP endpoints to confirm the signing certificate has not been revoked. If those endpoints are blocked or time out, verification can fail.

These two causes explain the cases where LENIENT does nothing. They also explain why the error can appear against an 8.1.34+ gateway.

Match what you see to the cause

Symptom Likely cause Action
Error only on 8.1.33-and-older gateways; 8.1.34+ and 8.3 open fine Unsigned launchclient.jar rejected under MODERATE Set signature.verification.strength to LENIENT
You set LENIENT, restarted the launcher, and the file says MODERATE again File edited while the launcher was running; overwritten on shutdown Exit the launcher fully, then edit
Works after the edit, breaks again after using a different launcher install Shared designer-launcher.json rewritten by the other launcher Standardize on one current launcher, or use pre-configured portable launchers
Works for one Windows user, fails for another on the same PC Config lives in each user's home directory; the second user still has the default Apply the edit under every user profile
LENIENT confirmed saved, cache cleared, still fails JAR modified in transit, or OCSP check failing Launch from the command line and read the logs; test off the proxy
Error against an 8.1.34+ or 8.3 gateway Signed JAR failing verification (proxy or OCSP) Same network diagnosis; the setting is not the issue

Check the gateway version first. If the failing gateway is 8.1.33 or older and newer gateways open, go directly to the config edit below.

Set signature.verification.strength to LENIENT with the launcher closed

This edit is client-side only. You close Designer sessions on your workstation. The gateway keeps running and production is not affected.

  1. Close every Designer session opened from this launcher, then exit the Designer Launcher. On Windows, check Task Manager for a leftover launcher or Java process and end it. If the launcher is still running when you save, it overwrites your change.
  2. Open ~/.ignition/clientlauncher-data/designer-launcher.json. On Windows, ~ is the user profile folder, so the path is %USERPROFILE%\.ignition\clientlauncher-data\designer-launcher.json.
  3. Find the signature.verification.strength key and change its value from MODERATE to LENIENT:
    ...
    "signature.verification.strength": "LENIENT",
    ...
  4. Save the file as plain text. Keep the quotes and the trailing comma intact. A broken JSON file causes a separate problem.
  5. Start the Designer Launcher, exit it again, and reopen the JSON. The value must still read LENIENT. If it reverted, a launcher process was still running during your edit.
  6. Launch against the 8.1.23 gateway. Accept the prompt to trust the unsigned launcher JAR. The Designer should then open.

The file sits in the user's home directory, so each Windows account has its own copy. On shared engineering PCs, or when you onboard new staff, repeat the edit for every account that launches Designers.

Run one launcher against every gateway version

Running an 8.1 launcher for legacy sites and an 8.3 launcher for new sites is the setup that breaks the edit repeatedly. Both launchers share designer-launcher.json and both write to it on exit. You end up re-editing the file every time you switch sites.

  • Use the latest launcher for everything. Current launchers are backward compatible. Launchers and Workstation from 8.3.8 open older gateways once verification is set to LENIENT. Uninstall the old launcher so nothing else writes to the file.
  • Isolate configs with portable launchers if needed. The Ignition User Manual section "Deploying Pre-Configured Launchers" describes how to deploy launchers with their own configuration. You can keep one set to MODERATE for 8.3 and 8.1.34+ sites and a separate one set to LENIENT for legacy gateways.
  • Know what you give up. LENIENT accepts an unsigned JAR after a trust prompt. MODERATE is the stricter default. Scope LENIENT to the launchers that actually connect to pre-8.1.34 gateways.

Chase the network path when LENIENT changes nothing

If the value is confirmed saved as LENIENT, the cache has been cleared, and the launch still fails, stop editing the file. The setting is no longer the issue.

  1. Launch the Designer Launcher from a command line and watch the console and log output during the failed launch. The log shows whether verification failed on the signature itself, on a revocation check, or on something else in the JAR. Without it, you are guessing.
  2. Look for proxy tampering. SSL inspection, web filtering, or endpoint security that repackages or scans downloads can change launchclient.jar in transit. Retry from a network path that bypasses the proxy, such as a direct connection to the gateway subnet. If that works, have IT exempt the gateway address from inspection.
  3. Look for blocked OCSP traffic. Revocation checks need outbound access to the certificate authority's OCSP responders. Filtered or air-gapped engineering networks commonly block this. Compare against a workstation that has outbound internet access.
  4. Compare workstations. If one PC launches the same gateway and another does not, compare their network paths and security software, not the gateways.

Confirm both gateway generations launch cleanly

  1. Launch a Designer against the 8.1.23 (or other pre-8.1.34) gateway. You should see the unsigned-JAR trust prompt, then the Designer opens.
  2. Launch against the 8.3 gateway from the same launcher. It should open with no trust prompt.
  3. Close the launcher completely, reopen it, and confirm signature.verification.strength still reads LENIENT in the JSON.
  4. Repeat steps 1-3 under every Windows account that uses the workstation.
  5. After upgrading any gateway to 8.1.34 or later, launch it under MODERATE. It should open by default, because it now serves a signed JAR.

Upgrade 8.1 gateways to 8.1.34+ and retire LENIENT

LENIENT is a workaround. Signature verification only protects you when the gateway serves a signed launchclient.jar, and that requires 8.1.34 or later. Moving 8.1 gateways to 8.1.34+ also gives the best compatibility for later upgrades to 8.3. After the upgrade, 8.3 launchers open Designers and Clients on default settings.

  • Take a gateway backup before every upgrade.
  • Test the target release in a development environment first.
  • Pick one target release, for example the latest 8.1.x, and roll it out across the whole fleet so all gateways match.
  • Some sites cannot take even a short production stop. Keep LENIENT on the launchers that connect to those sites. The launcher change itself needs no gateway downtime, only closed Designer sessions.
  • Once the last pre-8.1.34 gateway is upgraded, set the launchers back to MODERATE.

FAQ

What happens if I edit designer-launcher.json while the Designer Launcher is open?

The launcher writes its config on shutdown and replaces your LENIENT value with MODERATE. Exit the launcher and any lingering launcher process first, make the edit, then reopen the file after a restart to confirm the value held.

What happens if I set signature verification to LENIENT on an 8.3 launcher?

Gateways at 8.1.33 and older trigger a prompt to trust the unsigned launcher JAR, and the Designer opens after you accept. Gateways at 8.1.34+ and 8.3 keep launching normally. The trade-off is that you accept unsigned JARs, so limit LENIENT to launchers that connect to legacy gateways.

Do I need gateway downtime to fix Launch client jar invalid?

No. The fix is a client-side change to signature.verification.strength in the launcher's JSON. You only need to close your Designer sessions and the launcher; the gateway and production keep running.

What happens if LENIENT is saved and Launch client jar invalid still appears?

The cause is almost always a proxy modifying the JAR in transit or a failed OCSP revocation check, not the setting. Launch from the command line to capture the verification error, then retest from a network path that bypasses inspection. If it still fails there, stop and open a case with Inductive Automation support, and include the launcher log, gateway version, launcher version, and a description of your network security stack.

Back to blog