We have a RESTful API integration (python flask) that we interface with from Vision clients for access to our Netsuite accounting platform. We have a valid signed CA cert installed, however Ignition clients are unable to connect to it and we get the following exception. To me this seems like the client requires the certificate in it’s trusted certs, but I’m not sure how to accomplish this. The certificate is the same one we use for our Ignition web server and our clients and designer all work great with SSL. Any help is appreciated!
Traceback (most recent call last):
File "<module:common>", line 10, in callAsyncInvoked
File "<event:actionPerformed>", line 74, in get_customer_by_name
IOError: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
Ignition v8.0.3-rc1 (b2019072215)
Java: Azul Systems, Inc. 11.0.3
Edit: I should mention we had this working fine in 7.9.10, albeit with a different certificate.
when you say you have a valid signed CA cert installed, is it safe to assume that your certificate is signed by a CA that is recognized by the JRE by default? or is this signed with an internal CA whose chain of trust doesn’t end with a root CA who is trusted by the JRE?
We started enforcing certificate validity in 8.0. You should be able to drop the client certificate into the .ignition/clientlauncher-data/certificates directory which should add the client certificate to the java keystore for vision clients and designers.
If this doesn’t help i would recommend reaching out to support so we can give you better instructions based on your setup.
Thanks, we’ll try that addition to the clientlauncher-data dir. The cert is definitely recognized and works fine with all other java apps it’s used with. So we should be good! We’ll report back next week.
I’m not finding this directory on our linux gateway. A directory search returns no results for “clientlauncher-data”. Is it perhaps in a different dir on linux installs?
ah, ok. So in order to make this work, we’ll need to install the certificate on every client machine? No way for it to be issued with the packages when a client launches? This could be very cumbersome as we have dozens of clients that will require it.
Yes, that’s going to be what’s necessary right now. Cost of using your own CA, I guess.
In the future we might be able to figure out a way to have any custom certificates needed by clients available and distributed by the gateway, but it would require at a minimum that your gateway was set up with SSL.
edit: if you refactored your scripting a bit and made the HTTP calls all happen from the gateway scope somehow (system.util.sendMessage maybe?) then only the gateway would need the supplemental certificate installed.
I guess I don’t fully understand the difference in the CA. Our certificate works fine for Designer clients, and we have the gateway set for SSL…so I think I need help understanding what’s not actually working here…
Edit: just seeing your edit regarding the .sendMessage function, we can look into that. Thanks.
I’m only going off your original error message and description here, but what I’m gathering is that the the certificate for your Netsuite accounting platform is either self-signed or signed by a CA that is not in Java’s list of root CAs.
If you want to send us the certificate(s) we can take a look and see what we’re dealing with.
Right, our certificate in use is the same wildcard cert we are using for our Ignition gateway SSL. So it should be good as far as Java’s list goes.
subject=/OU=Domain Control Validated/OU=EssentialSSL Wildcard/CN=*.northwindsolutions.com
issuer=/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA
AFAIK, “COMODO RSA Domain Validation Secure Server CA” is only an intermediate certificate in a longer chain and it is not part of Java’s root CA list.
You’re probably going to need to ensure the entire chain, from your leaf wildcard certificate all the way to whatever the root is (AddTrust issuing to Comodo from some brief googling), is added to the supplemental certificates on the gateway and/or .ignition/clientlauncher-data/certificates on clients.
The client launchers should allow you to specify some additional JVM arguments. If you add -Djavax.net.debug=all then there might be some additional useful info in the console of the client once you attempt the webservice call.
The same applies on the gateway, with the additional parameter being added to ignition.conf and the messages showing up in the wrapper.log files.
Hi Kevin, I've had no success getting this to work. I've added the .crt to the java jdk cacerts on both client and server without any change. I think I need to get some support on this, does IA have someone in support that can deal with this, or should I be looking to a 3rd party? Thanks.
You should be able to call support and get help with this. They probably deal with it somewhat frequently now. Make sure you have all of the certificates that comprise your certificate chain on hand.
edit: also, I never asked this, but your clients are making their HTTP requests to the netsuite server with a URL that includes .northwindsolutions.com right?