Gateway Event with system.net.httpGet error

Ignition
1

In Ignition 8.0.16 I have code that builds a URL then uses system.net.httpGet( url=siteUrl, headerValues=siteHeader.

It works when called from a script; it works when called from the Script Console; it works when I paste it into a browser (Chrome and Edge); it works in a MinGW64 session; it works when running directly on the Gateway Server and from my workstation.

When I call it in a Gateway Event script, specifically, via system.util.sendRequest, or in a Tag Event script, it generates the error:

IOError: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target

It errors even when I hard code the working URL directly in the Gateway Event script or Tag Event script.
Is there a security setting or a bug that’s getting in the way?

I am moving the code from Ignition 7.9 where a tag event script calls a shared script (has been in production for 4 years now). I need to find a robust way for tag events in 8.x to both GET and POST to a web API and would prefer to have the script in a sharable location to be called from UDT tags.

I’m open to alternative solutions.

2

For a variety of reasons, I evangelize system.net.httpClient pretty heavily, but (aside from the bypass_cert_validation flag) it’s not the solution to your issue as it stands.
The path validation exception indicates to me that your IT group might be loading a custom root certificate at the OS level - that would be why browsers, consoles, etc can hit it, and you can even hit it from inside the designer - but the gateway host may not have that custom cert loaded.

3

Actually, I can hit it from the Gateway Host - at least I think I can.
When I use a Remote Desktop login and run the Designer on the Gateway, it still works in script, browser and script console.
These API calls were working on the same server before upgrading from 7.9 to 8.0.
The OS and server configuration is the same but the version of Ignition is different.

4

So from 7.9 -> 8.0 we stopped using the system’s Java and started using our own. It’s got its own cert chain embedded, so it’s possible:

  1. Something like what I first suggested happened, so Java’s not aware that it should ‘trust’ your bespoke cert.
  2. Your service is behind an expired/outdated/etc cert, and Java isn’t trusting it while internals are. That’s less likely, because browsers really don’t like outdated certs, but theoretically possible.
1 Like
5

It is working now by doing the following:

  1. Pasted the URL into the browser address bar
  2. Clicked on the security icon (padlock) to see the certificate in use
  3. Exported the certificate file
  4. Copied the certificate file to:
    C:\Program Files\Inductive Automation\Ignition\data\certificates\supplemental
  5. Restarted the Ignition service
1 Like
6

I am getting the same TLS certificate error message after exporting it using a web browser and copying that file into C:\Program Files\Inductive Automation\Ignition\data\certificates\supplemental and restarting the service, I'm still getting the error. Any ideas?

7

If it’s a CA signed certificate (i.e. a chain), and not a single self signed certificate, it’s the root certificate you need to import.

What scope is the http call being made from?

8

Kevin,
Currently its a perspective button press event script:
def runAction(self, event):
url = "https://grevlablnk.nrb.inside/#!/"
myClient = system.net.httpClient()
response = myClient.get(url)
system.perspecitve.print(response)

If that's what you're asking regarding scope.
I don't know for certain where the certificate on the LabLink API server comes from but the IP address of it private so I think it may be self signed certificate. I'll ask that question. In fact I'm just going to add another email to the CC on this.
Elias,
please note Kevins response in this chain.

Keith

9

finally got the root cert put in that directory and the SSL error is gone. Thanks.

1 Like