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
LENIENTedit gets overwritten withMODERATEthe 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.jsonon 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 withMODERATE. -
LENIENTon 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.
- 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.
- 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. - Find the
signature.verification.strengthkey and change its value fromMODERATEtoLENIENT:... "signature.verification.strength": "LENIENT", ... - Save the file as plain text. Keep the quotes and the trailing comma intact. A broken JSON file causes a separate problem.
- 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. - 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
MODERATEfor 8.3 and 8.1.34+ sites and a separate one set toLENIENTfor legacy gateways. -
Know what you give up.
LENIENTaccepts an unsigned JAR after a trust prompt.MODERATEis the stricter default. ScopeLENIENTto 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.
- 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.
-
Look for proxy tampering. SSL inspection, web filtering, or endpoint security that repackages or scans downloads can change
launchclient.jarin 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. - 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.
- 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
- 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.
- Launch against the 8.3 gateway from the same launcher. It should open with no trust prompt.
- Close the launcher completely, reopen it, and confirm
signature.verification.strengthstill readsLENIENTin the JSON. - Repeat steps 1-3 under every Windows account that uses the workstation.
- 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
LENIENTon 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.