Since I updated from Ignition 8.1.32 to 8.1.37, when I launch the applications from Vision Client Launcher, the following error window appears:
"Launch client jar Invalid. This launch client jar signature is invalid. Contact an administrator"
In visionclientlauncher.log, the following trace is seen:
ERROR [LaunchClientJarService ] [2024/02/27 12:35:57]: Launch client jar Invalid
java.security.cert.CertPathValidatorException: Unable to determine revocation status due to network error
at java.base/sun.security.provider.certpath.PKIXMasterCertPathValidator.validate(PKIXMasterCertPathValidator.java:135)
at java.base/sun.security.provider.certpath.PKIXCertPathValidator.validate(PKIXCertPathValidator.java:224)
at java.base/sun.security.provider.certpath.PKIXCertPathValidator.validate(PKIXCertPathValidator.java:144)
at java.base/sun.security.provider.certpath.PKIXCertPathValidator.engineValidate(PKIXCertPathValidator.java:83)
at java.base/java.security.cert.CertPathValidator.validate(CertPathValidator.java:309)
at com.inductiveautomation.ignition.launcher.common.signverify.DefaultSignatureVerifier.verify(DefaultSignatureVerifier.java:179)
at com.inductiveautomation.ignition.launcher.common.service.LaunchClientJarService$LaunchClientJarTask.verifyLaunchClientJar(LaunchClientJarService.java:204)
at com.inductiveautomation.ignition.launcher.common.service.LaunchClientJarService$LaunchClientJarTask.call(LaunchClientJarService.java:166)
at com.inductiveautomation.ignition.launcher.common.service.LaunchClientJarService$LaunchClientJarTask.call(LaunchClientJarService.java:138)
at javafx.concurrent.Task$TaskCallable.call(Task.java:1426)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at javafx.concurrent.Service.lambda$executeTask$6(Service.java:728)
at java.base/java.security.AccessController.doPrivileged(AccessController.java:399)
at javafx.concurrent.Service.lambda$executeTask$7(Service.java:727)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at java.base/java.lang.Thread.run(Thread.java:840)
Caused by: java.io.IOException: Received HTTP error: 303 - See Other
at java.base/sun.security.provider.certpath.OCSP.getOCSPBytes(OCSP.java:280)
at java.base/sun.security.provider.certpath.OCSP.check(OCSP.java:195)
at java.base/sun.security.provider.certpath.RevocationChecker.checkOCSP(RevocationChecker.java:785)
at java.base/sun.security.provider.certpath.RevocationChecker.check(RevocationChecker.java:369)
at java.base/sun.security.provider.certpath.RevocationChecker.check(RevocationChecker.java:343)
at java.base/sun.security.provider.certpath.PKIXMasterCertPathValidator.validate(PKIXMasterCertPathValidator.java:125)
... 16 more
We are getting the same error in different PCs with Windows 10 and Windows 11, the point is that IT deparment is not willing to open these PCs to external network traffic.
Everything worked fine for these PCs in Ignition 8.1.32 and previous releases.
I tried cache deletion, full clean re-installation ...
My question is how to turn off certification revocation check in Vision Client Launcher 1.1.37 (Ignition 8.1.37) ?
It looks like you are hitting a 303 when attempting to reach out to the OCSP server when checking for revocation checks. I would check with your IT department about that.
You have a few options:
It will work better by just denying the connection or returning something like a 500 probably. I think this is the "proper" fix for this, as the launcher will "soft-fail" if it can't reach the OCSP server, but since a 303 is returning it has no chance to soft-fail.
use the older launcher. there isn't a requirement that the launcher version matches the gateway you are targeting, quite the opposite in fact.
If the previous two options aren't at all feasible, you can supply a system prop for the launcher -Dlauncher.version=dev which bypasses this mechanism entirely. This shouldn't be the route you go unless something is completely blocking your ability to do step 1 or 2
I will make a ticket to improve this in the 8.1 branch though. A number of new options for this are already in our 8.3 development branch, but I will pull out the "air-gapped" option which turns off revocation checks but still performs cert path verification checks and target 8.1 for it.
Hi @jcoffman , thank you very much for your prompt reply with all the options. So far, we are taking option 2.
Since it is possible to hide the update warning message for the launcher ("version.updates.prompt": false in vision-client-launcher.json), it seems the best choice for us. Thanks!
Did you alter the strength requirement within the launcher configuration json? Also, Im assuming that you updated the launcher as well to 1.1.41 along with the gateway version update?
after installing the update I re downloaded the client from the gateway and installed it. I am assuming that means I got the latest launcher. Still did not work. My issue was the launcher could not access the internet. I fixed that, but that is going to be an issue with production systems that are meant to be segmented from the internet.
IA needs to remember that most modern process control systems are isolated. I should not have to dig through config files of launchers to make sure clients work properly. Make it a setting in the gateway at the very least so when they are deployed they work.
This is precisely the reason that the default level is a "soft" fail for revocation checks. this does cause a possible delay waiting on a timeout with the revocation service depending on your network, but the launch will succeed if the revocation service cannot be reached in a typical network. However, if you do experience issues on your network we expose this option for tweaks.
Security and convenience often pull in opposite directions, but I feel that this is a sensible middle ground for most situations.
I would suggest that the launcher queries the signature verification strength from the gateway the user is trying to connect to and processes the request according to that gateway's strength setting. The strength setting would be associated w/ the client, rather than the launcher. This is the way, and honestly should have been the way all along.
I get it, more security, blah blah, but don't get it that now we get to play "roll your own", "downgrade dance", and "Custom Deployment" as the default for systems that are explicitly locket out of the internet. With 15+ installations (all offline) and 100 users, I can tell you this is a PITA. We have contractors and non-domain computers that occasionally access our projects. I can't easily push a custom launcher to them. Instead, it's, "Hey make sure to download this launcher from before 8.1.34, and don't update."
My very humble and probably ignorant opinion is that this could have been handled way better with far less intervention and intrusion. I've read a few comments, and it seems IA is dodging the accurate response, "Yes, we rolled out a feature that requires internet access for launchers to function as intended, without delay or modification." Tell me I'm wrong, but that just doesn't make sense to me.
So, you want the target that the launcher is trying to verify to supply the verification criteria? Like a fox in the henhouse?
To be secure in today's environments, certificates are supposed to be verified. Any setting to reduce that security has to be deliberate, and not involve the target to be verified.
If you configure our network such that outbound requests to the certificate revocation servers immediately fail, instead of being in an indeterminate state, certification revocation checks take very little additional time, because there's no timeout to wait for.
That's the actual fix here.
You are, of course, welcome to continue to use old versions of the launchers - we take great pains to make them backwards and forwards compatible as much as we possibly can.
But there's no way around a few things:
Certificate revocation checks are a security benefit.
Certificate revocation checks, by definition, require a connection to an outbound service.
Connections to external services, by definition, need some built in tolerance for flaky networks. If you're in an air gapped environment that's not configured to quickly reject outbound connections, the launchers have no way to differentiate an air gapped network from a spotty network. Except for the configuration options we provide as an escape hatch.
Contrary to a vocal minority of folks, and what you and I would agree is common sense, the majority of Ignition deployments in the world are not air gapped, and at least allow outgoing network connections without issue. For the majority of folks out there, they get an effectively unchanged experience but improved security.
The UX for soft revocation failure on some air-gapped networks did end up sucking. It should have been a 15s timeout, but it looks like it's ending up a multiple of that, perhaps based on the number of endpoints in the OCSP and CRL distribution points.
I'm not sure there's much we can do about it now, but going forward I think we can work with QA to do additional offline testing in an environment that's more representative of these kinds of air-gapped networks. I'm certain nobody launched a Designer, experienced a 75s timeout or whatever, and said "yeah, that's fine".