Fix Ignition 7.7 Client Java Certificate Launch Errors

On the panel, the fault shows up at launch. The operator clicks the project, Java Web Start starts to load, and then a Java certificate or security error stops it. The client never opens. In the case covered here the gateway ran 7.7.2 and the clients ran Java 1.8.0_31 (build 1.8.0_31-b13, HotSpot 64-Bit Server VM 25.31-b07). A second site on the same Java build hit the same error. It then cleared without any change to the clients.

That last detail points to the cause. If nothing changed on the client and the error went away, the fault was never in the client install.

Stop Reinstalling Java

These are the fixes engineers usually try first, and why each one fails:

• Reinstalling Java 8. This was tried here and the error came back. A fresh JRE runs the same certificate validation against the same external services. If the validation path is broken, the new install fails the same way.
• Reinstalling or restarting the gateway. The gateway serves launch files and signed JARs. It does not decide whether the client JRE trusts them. A restart only helps if the gateway itself is serving broken content, and you would see that on every client, not just some.
• Rolling Java back or forward blindly. A different build brings a different security baseline. That can hide the symptom or add new prompts. It does not tell you which check failed.
• Lowering Java security settings on every client. This can get operators running. It also turns off the check that failed, so you never learn why it failed.

Start with the validation path instead.

Understand the Real Cause: The Certificate Validation Path

Ignition clients launch as Java Web Start applications from signed JARs. Before any code runs, the client JRE validates the signing certificate chain. It checks three things:

1. Chain and dates. Each certificate must chain to a trusted root, and the current date must fall inside each certificate's validity window. The JRE judges that window using the local system clock.
2. Revocation. Depending on the Java Control Panel settings, the JRE contacts the issuing CA's OCSP responder, downloads a CRL, or both. It does this over the client's network path, including any proxy set in Java network settings.
3. Cache. The JRE compares cached JARs and cached validation results with what the gateway serves now.

An error that clears by itself, with no client change, fits the revocation step. The CA's responder may have been slow or down. A firewall or proxy may have briefly blocked it. A cached revocation response may have expired and been fetched again. When the external endpoint recovers, the launch succeeds again.

Plant networks make this worse. Clients on isolated OT segments often cannot reach public OCSP or CRL hosts at all. Whether that becomes a hard failure or a quiet pass depends on the client's revocation settings.

Run These Checks in Order

Start here. Each check is quick, and they are ordered by how often they turn out to be the fault.

1. Capture the full exception. In the Java Control Panel, open the Advanced tab and turn on the Java console and tracing/logging. Relaunch the client and copy the full stack trace. The exception text tells you whether the chain, the dates, or the revocation check failed. Do not troubleshoot from the dialog summary alone.
2. Check the client clock. Compare the client's date, time, and time zone with a known-good source. A wrong date makes a valid certificate look expired or not yet valid.
3. Test revocation reachability. From the failing client, test whether the CA's OCSP or CRL URL is reachable. You can read that URL from the certificate details shown in the Java security dialog or the console trace. Test it through the same proxy Java uses.
4. Compare against a working client. If one client launches and another does not, compare their Java build, clock, proxy settings, and revocation settings side by side.
5. Clear the Java cache. Delete cached files from the General tab of the Java Control Panel, or run javaws -uninstall. Then relaunch from the gateway.

Apply the Fix

Match the fix to what the console trace told you:

1. Revocation endpoint unreachable, clients have internet access by design. Open the path through the firewall or proxy to the CA's OCSP and CRL hosts. Enter the proxy correctly in Java network settings. Retry the launch.
2. Revocation endpoint unreachable, clients are on an isolated network by design. Set a deliberate policy in the Java Control Panel revocation options, and apply it the same way on every client. Keep this as a documented site decision, approved by whoever owns OT security. Do not make it a one-off change on one PC.
3. Transient CA outage. If the endpoint is normally reachable and the error cleared by itself, no client change is needed. Record the time and the exception text, and watch for it to happen again.
4. Clock wrong. Point the client at the site time source and correct the time zone. Relaunch.
5. Stale cache. Run javaws -uninstall or delete the cached files, then launch again from the gateway's launch page.

Verify the Launch

• Launch the project from the failing client with the Java console open. The trace should show certificate validation completing with no security exception.
• Relaunch once more after the cache has repopulated. This confirms the fix holds, not just a lucky first retry.
• If revocation was the cause, launch from a second client on the same network segment. It should pass without any per-client changes.
• Log the Java build, gateway version, and revocation settings you ended up with. The next person hitting this error needs a known-good baseline.

Avoid These Recurring Traps

• Calling a self-clearing error fixed. If it cleared without a change, the external cause is still there and will come back. Keep the console trace.
• Silent Java auto-updates. Each JRE update can tighten security defaults. Freeze the Java build on HMI clients and test updates on one machine first.
• Proxy set in Windows but not in Java. Java network settings can differ from the OS. Check both.
• Mixed Java builds across clients. Different builds validate differently, and that looks like a random fault. Standardize the build.
• Disabling revocation checks on one PC to get production running. The PC works, nobody records it, and the whole fleet ends up inconsistent.

FAQ