OAuth2 and LabVIEW — A Bug in LabVIEW’s SSL Certificate Handling

After discussing a LabVIEW 2020 bug in my last post in early June, I let the wind go out of my sails and set aside the new version for awhile. Around the same time, one of my other OAuth2 applications stopped working. It wasn’t urgent and I didn’t investigate right away, but it turns out that I found another LabVIEW bug lurking in the way SSL certificates are handled.

Now before anyone panics, almost no one will run into this bug. It does impact all recent versions of LabVIEW–2020 and 2019 for sure, but to be honest, I didn’t go back to earlier versions. I filed a bug report with NI, but it’s not clear if they’ll prioritize fixing it. Details follow…

As I’ve mentioned before, I use Wireless Sensor Tags, which are inexpensive and useful sensors. I have a few of the temperature/humidity monitors in the house, one of which I use to control a faulty beverage refrigerator.

Writing a LabVIEW program to access the data from these sensors is what motivated this entire series of blog posts on OAuth2. In my earlier posts, I showed you the Google APIs, since they are probably more relevant for most of my readers. But personally, I’m more interested in having access to my Wireless Sensor Tag data.

That’s what stopped working in early June of 2020. It was working fine before that, but suddenly, I started getting this error…

When I first saw it, I thought, “that’s odd”, but didn’t really think I’d run into a LabVIEW bug. I ran my code that used the Google APIs, and it worked fine. It was something about accessing “my.wirelesstag.net”, the URL for the Wireless Sensor Tag API.

Pretty soon, I ran an “SSL Checker” (there are several websites where you can verify that an SSL certificate is valid) on “https://my.wirelesstag.net”. SSL stands for Secure Sockets Layer, and it depends on certificates that help you ensure that the website you think you’re talking to is the right one. When you use the “https” protocol (as opposed to the unencrypted “http” protocol), the certificate of the website is used when you open up a connection from a client such as LabVIEW or a web browser.

Sure enough, there is a problem with the certificate for “https://my.wirelesstag.net”…

Ahhh! One of the certificates in the certificate chain expired on May 30, 2020. That explains why I didn’t notice this problem until early June.

Initially, I assumed that the owner of “https://my.wirelesstag.net” had an out-of-date certificate and they’d fix it. So I ignored the problem for awhile. I checked again a week or two later, with no change.

In the meantime, I could work around the problem in LabVIEW by turning off the certificate check. Here’s the original VI which does an HTTP POST message:

You can add an input to “OpenHandle.vi” to turn off the check…

This lets the VI run without the certificate error, but running without secure communications is not an acceptable workaround.

Eventually, I noticed the following words in the SSL check…

The certificate should be trusted by all major web browsers (all the correct intermediate certificates are installed).

Hmm, I wonder what that means. So I decided to dig a little deeper. With the caveat that I am not an expert in the nuances of SSL certification, I learned that the chain to the expired root certificate is there for compabitlity with very old systems…

Sectigo at present offers the ability to cross-sign certificates with the AddTrust legacy root to increase support among very old systems and devices. This root is due to expire at the end of May, 2020. Any applications or installations that depend on this cross-signed root must be updated by May, 2020 or run the risk of outage or displayed error message.

From https://sectigo.com/resource-library/sectigos-addtrust-root-is-soon-to-expire-what-you-need-to-know

Well, apparently LabVIEW is an example of a “very old system or device”. And to be a little more precise, it’s the ni-curl library, which is an internal library that NI created to wrap the curl library, which is a commonly used library for talking to websites. I’m guessing that the ni-curl wrapper is based on a very old version of curl and hasn’t been updated in years. Another possible explanation is that the file C:\Program Files\National Instruments\Shared\nicurl\ca-bundle.crt is out of date and hasn’t been updated in years. (I believe this file contains the list of trusted certificates.) I tried (not very hard) to get more information from NI, but didn’t get an explanation.

Anyway, my naïve explanation of the bug is that NI’s curl library should be trusting that an earlier certificate in the chain is valid, and therefore trusting “my.wirelesstag.net”. But either ni-curl doesn’t trust the earlier certificate or it is using an outdated algorithm for trust, which leads to the “my.wirelesstag.net” certificate being rejected.

While I wait for NI to sort this out, I also figured out a better workaround than turning off security communications. You can download the unexpired intermediate certificate and have LabVIEW use it directly. So my new block diagram looks like this:

After every call to OpenHandle.vi, I inserted ConfigSSL.vi, with the path to the downloaded .crt file wired in. With this approach, I can once again have secure communications. This does mean that I will have to deploy the downloaded .crt file with my application, but it’s small and won’t be an issue. Note that I tested this solution in both LabVIEW 2019 and 2020.

If anyone from NI is reading this and knows more, I encourage you to comment below.

Thanks for reading. I hope to post soon about the LabVIEW web server changes in LabVIEW 2020.

Read the other articles in this series:

• Part One — Setting up a LabVIEW Web Service Callback Function
• Part Two — The Authentication Process
• Part Three — Improving the Example
• Part Four — Reusability
• OAuth2 and LabVIEW 2020, Using the New SHA256 VI
• OAuth2 and LabVIEW 2020, A Bug in the SHA256 VI
• OAuth2 and LabVIEW — A Bug in LabVIEW’s SSL Certificate Handling
• OAuth2 and LabVIEW 2020, Changes to the LabVIEW Web Servers
• OAuth2 and LabVIEW — Replacing the Web Server