[Ignition 8.0.7] Windows Launchers cannot be configured to use Windows Certificate Store

I’m trying to figure out a simplified way to deploy Ignition Launchers for users that is simple and painless. I would also like to have maximum security and control so trying use SSL for all communication between Client and Servers since our IT Security team point it out all of the time if not encrypted. I have internally signed Web Server Certificates from the company Certificate Authority which I’ve put in correct place so the web site correctly uses it and serves the page with that Cert.

I would like to avoid downloading and updating cacerts trust files with these certificates for every jre and java app that gets deployed so prefer to use the Windows Certificate Store on windows machines.

On the server I’ve added the following “Java Additional Parameters” so that the Windows Certificate Store will be used on the Windows server for validating Certificates and that seems to work correctly.

## ignition.conf ##
wrapper.java.additional.2=-Djavax.net.ssl.trustStore=NUL
wrapper.java.additional.3=-Djavax.net.ssl.trustStoreType=Windows-ROOT
wrapper.java.additional.4=-Djavax.net.ssl.keyStoreType=Windows-MY
wrapper.java.additional.5=-Djavax.net.ssl.keyStore=NONE
wrapper.java.additional.6=-Djavax.net.ssl.keyStoreProvider=SunMSCAPI
wrapper.java.additional.7=-Djavax.net.ssl.trustStoreProvider=SunMSCAPI

The company centrally distributes the certificates on Windows machines using Enterprise Policies so browsers can find trust those CA certs so machines have the correct CA in Windows Certificate Store.

Now my issue is trying use the launchers from Inductive downloaded from the server do not work. I can add the server manually to the Launchers (http://:8088:8043) and it will fail (if I use http://:8088) it will connect since it ignores ssl.

In theory on client machine I can either add the same flags from above to global JAVA_TOOL_OPTIONS environment variable or _JAVA_OPTIONS or even launch the Designer Launcher from command line with the -D flags explicitly. Or add the flags to the net.properties or java.security files I guess.

Unfortunately it would appear that the JRE shipped as part of designer lacks the sunmscapi.dll and probably a few other things stripped out it seems. If I junction the JRE folder with the one in %USERPROFILE%.ignition\cache\resources\runtimes\11.0.5 then this will work.

So I guess options are repackage the designer launchers ourselves with different JRE (like one in runtimes folder) or edit the cacerts file and add additional certificates which still requires new deployment package. I dont really like the cacerts editing because I have to manually update that with the company internal certificate authority certs which in theory can change.

Is there a better approach since I’m sure that we will not be getting certificates signed by other authorities?

Can your IT automation place the certificates that need to be trusted into the $USER/.ignition/clientlauncher-data/certificates folder on machines that will be launching clients and designers?

The same can be done on the gateway using $IGNITION/data/certificates/supplemental as well. Then you don’t have to mess with using the windows certificate store.

1 Like

Thanks still not ideal but about what I thought. I don’t think I can get IT to support since it is application specific folder or setting. I suppose this is a variant of the cacerts issue in that case. I suspect I still have to deploy a custom repackaged launcher that either includes the certs or is itself capable of extracting the certs from the Windows Store as part of install and updating those folders or the cacerts. Anyway probably need to create my own installer to be able to add default servers and add shortcuts for users. I’ll pass it through that team and how badly security wants to deal with it but thanks for feedback.

Switching to perspectives is probably better long term strategy but still quite a bit of work for us to adopt right now.

Not sure how much it helps your case, but we are working on UI flows for the launchers and mobile apps so that they present the user with a choice to accept or reject an untrusted certificate the first time it encounters one. I think it’s all still in the design/planning stage though.