Is TLS broken in LabVIEW since around the start of October?

[Brett_Percy]

Hi all,

This is a bit of a long shot, but is anyone else calling a secure WebSocket endpoint from LabVIEW and had it break recently? It's suspiciously close to the date of Let's Encrypts old cert expiry date..

I have some code I have been working on for a few months, and up until I picked it up again this week it had been working fine.  It's now failing to connect to the WebSocket address, with an error message indicating that a certificate is out of date

I have checked the endpoint using wscat, which is a command line tool that's available on npm [https://www.npmjs.com/package/wscat] - the endpoint still works fine, I am able to manually authenticate and send it data.  So it looks a lot like the problem is in the LabVIEW code

This uses MediaMongrel's excellent WebSockets toolkit from https://github.com/MediaMongrels-Ltd/LabVIEW-Secure-WebSockets-Addon

I've attached what I think is the important part of where the error is occurring.  The specific error is -715047 at Start TLS

I've exported the DER from the current ISRG Root X1 cert in Win10 and tried inserting that into the TLS configuration but to no avail - this part is new, the built-in certificate handling was working fine before

Cheers
Brett

[rolfk]

Quick and not always easy solution would be to upgrade to LabVIEW 2021. The HTTP Client VIs in LabVIEW use curl and OpenSSL internally and did in the past only use the OpenSSL certificates that were installed with the software. In LabVIEW 2021 they updated the OpenSSL implementation used and enabled it to directly use the OS provided key store to verify certificates. Your Windows OS should long ago already have included the ISRG Root X1, as you allude to yourself. With the LabVIEW 2021 HTTP Client VIs this should be automatically picked up.

If upgrading to LabVIEW 2021 is not an option, or if you just want to see a more versatile and functional Encryption library with a lot of different encrypted network protocol support, you might also want to look into this: https://lavag.org/topic/22223-whod-like-a-sneak-preview-of-ecl-version-4/?tab=comments#comment-13725...

It's a commercial product, so don't expect to get a freebee, but it's quite well made.

[Brett_Percy]

We're already upgrading from 2011? (I think) to 2020, so going to 2021 is not a big stretch.  I might try that out

Thanks Rolf,

Brett

[cordm]

Not sure if this is related, but at the end of september (before root CA expirtation) we had a similar problem where the cRIO clients could not talk to the SystemLink server. The error code was from the HTTP library "Could not verify the authenticity of the server" (363507). The web interface still worked fine. The certificate (also from Let's Encrypt) was still valid but the error only went away after updating the certificate. We also had certificate problems in august with older cRIO firmare when when the new root ca was introduced. So maybe force a certificate renewal and see if that helps.

[billko]

Perhaps this?  I believe our IT disabled TLS 1.0 and 1.1 due to security flaws.

[DrSean · Accepted solution]

I have had the exact same problem - previously working code involving the HTTPS & Secure Websocket clients stopped working when I went back to it this month. If it helps anyone:

To fix the HTTPS client problem I simply replaced the LabVIEW ca-bundle.crt located in "C:\Program Files (x86)\National Instruments\Shared\nicurl" with the latest CA certificates extracted from Mozilla from the curl website (best to backup the original LabVIEW file though!). This, however, did not solve the secure Websocket client issue, which continued to throw the -715047 error at Start TLS.

To fix the secure Websocket client issue I had to set the "load OS trusted CAs?" to false in the "New TLS Configuraton" VI. I then loaded in the LabVIEW ca-bundle.crt certificates to memory & added them to the trusted certificates in the TLS configuration when initialising the SSL/TLS. I later found that disabling "load OS trusted CAs?" alone seems to be enough to get things going again.

Sean

[Brett_Percy]

This is brilliant, thanks DrSean

---

To fix the secure Websocket client issue I had to set the "load OS trusted CAs?" to false in the "New TLS Configuraton" VI. I then loaded in the LabVIEW ca-bundle.crt certificates to memory & added them to the trusted certificates in the TLS configuration when initialising the SSL/TLS. I later found that disabling "load OS trusted CAs?" alone seems to be enough to get things going again.

My solution is basically what you have for your Web Service - the only difference being that I exported the ISRG Root X1 certificate from Window's certificate store and passed that into Add Trusted Certificate To TLS Configuration

The part I missed on the first try was that if you don't set load OS trusted CAs? to false in New TLS Configuration, passing in a valid certificate doesn't fix the problem

Cheers
Brett