Since upgrade to version 8.1.34, on my ot network (with no internet connection) my designer takes longer to open because of this message:
Verifying Signature of Designer
Any idea what is causing this? Even if I configure a non https connection to the gateway, samething. So it doesn't seems to be related to certificates.
Thanks
I believe this is the new signature verification security measure... basically we're now cryptographically verifying that the executable bootstrap JAR the launcher downloads from the gateway is unmodified and signed by IA.
What kind of hardware are you experiencing this delay on and how long is it?
@jcoffman probably has more details.
Ok, I understand.
It's on a vsphere with 32 virtual processor Xeon 5315Y Gold 3.20Ghz, 64 GB Ram.
(that the vm that the designer is running on)
I think this is probably the cause of the delay. There will be an attempt to check for certificate revocations, and you're probably running up against a timeout. The failure is soft, though, and that's why you can continue to launch.
Yes, that was my first impression since my gateway in the IT network with internet has no issues.
Kevins statement is correct. there is a timeout with a soft fail if revocation checks fail. This may result in a slight delay when launching, but shouldn't prevent launches.
OK, but it's annoying.
Are industrial networks more and more without internet access?
I find it bizarre (like the projects template not being available) because of lack of internet.
Less and less, in reality...
I understand the slight delay can be frustrating, but this provides a robust industry-standard way to verify the authenticity of jars downloaded over the internet. the soft-fail mechanism is the default we use specifically because most launch cases are on networks without internet access. The "strict" mode would actually require a connection to one of the revocation endpoints (ocsp.digicert.com or cacerts.digicert.com) which is why its not the default (but can be turned on in the launchers' config JSON)
You could get with IT to allow comms to the OCSP server if its a blocker, but typically this type of thing wouldn't be a "blocker" but an annoyance and the trade-off for security here is a much higher need than the delay in launching, especially considering its a fixable problem with modern IT solutions.
I agree also for the security reasons.
I will check with IT if they are willing to let that connection pass threw the firewall.
Thanks
I'm guessing there's no way to disable this? Is there a way to shorten the timeout? This took about 1:15 on an OT network of one of our clients. About 1/2 the time is the progress bar "bouncing" back and forth, then the 2nd half is solid gray progress bar, so not sure if there's 2 parts to the verification, but this more than what I would call a slight delay. If this can have a shorter timeout it would help for networks without internet access (I haven't tested this on Edge, but assume the time would be the same), but we've been trying to push this as a PanelView replacement and many of these won't have internet at all, and this delay on a restart of the system just slows things down.
Is it possible to package a cached and encrypted set of verified signatures with the gateway so that it can do a failover to the cached copy on the local network? This would still allow for signature verification to speed this up even more. Unless someone got ahold of your private key, it should still be secure. Maybe not make it default, but allow a launcher parameter to set it to default to local verification or shorten the timeout before failover or even shorten the soft fail.
Consider having your isolated network resolve the domain names to addresses that exist, but have no web server, and are configured to actively reject the connections (REJECT instead of DROP in any firewall rules). I would expect that to short-circuit the timeouts.
Yes, something like this would help.
No, it's not signature verification itself that is taking a long time, it's certificate revocation checking, which can't be cached. It's timing out trying to contact the OCSP server and the way this network is setup must be causing it to be passively rejected rather than actively rejected, as Phil suggested.
Maybe we can add an option to the launcher config to disable revocation checking, but it wouldn't be enabled by default.
I just added the following lines to the hosts file of the computer running the designer/client for Windows and this sped it up to only taking 30 seconds which is much less bothersome now.
127.0.0.1 ocsp.digicert.com
127.0.0.1 cacerts.digicert.com
You might want to use wireshark to see if it is trying some additional domain name. I would expect the delay to go to zero if you get them all.
Did a wireshark capture on DNS queries, and found a couple more. In fact, I didn't see it reach out to cacerts.digicert.com, so removed it.
There's also info here on what domains and IPs DigiCert uses: New Dedicated IP Addresses
Here's the final lines added to the hosts file on Windows to make this instantly fail (only pops up for a fraction of a second now).
127.0.0.1 ocsp.digicert.com
127.0.0.1 crl3.digicert.com
127.0.0.1 crl4.digicert.com
Has anyone looked into the Windowsregistry if you can turn off the check?
I did a quick check but could not find an option for it in HKEY_LOCAL_MACHINE\SOFTWARE\Inductive Automation\Ignition
My system is also on an isolated network, with multiple clients on different locations, so I'm not fond of the idea of modifing the host file.
Then place a DNS server in the isolated network to give the necessary responses.
Really glad I found this post. This delay on start up is brutal. I can't imagine there are very many systems with internet access...we're already struggling to get buy in and an almost 2 minute delay is a hard sell. Hopefully the DNS entries here will help us out.
Thanks pturmel, I will look into that.