Error 363507 Labview could not verify authenticity of the server

[tsethi]

I've been encountering an intermittent issue with a software built using LabVIEW 2018 when making HTTP calls to a server. The problem occurs on some test stations but not on others.

Our setup: We manually add the certificate to both the ni-curl/ca-bundle and the Windows Microsoft MMC.

To eliminate potential software or OS issues, we installed LabVIEW/TestStand from the same source, used the same test software, and the same offline copy of Windows OS. Despite this, some computer systems are affected. On systems where the LabVIEW test fails, it never works, even after reinstalling the OS and LabVIEW.

We ensured all NI-related services were allowed in the firewall settings to rule out IT firewall issues.

In LabVIEW, I made the following changes to address this:

1. Set the flag to False for Verify Server in OpenHandli.vi.
2. Updated the code to add ConfigSSL.vi and point to the certificate file.

Unfortunately, none of these approaches have resolved the issue.

I'm looking for recommendations.

Thanks.

[tsethi]

bumping up the thread

[PhillipBrooks]

I was just reading this last week.

https://stravaro.com/2020/08/oauth2-2020-part-3/#more-1023

Looks like you read that 🙂

If you are hosting the certificate from the local disk, maybe the cert file is the problem; corrupted, permissions issue or missing?

[tsethi]

Thanks PhillipBrooks.

Unfortunately those suggestion did not work. Putting the flag of False for Verify Server in OpenHandli.vi did not help either so not really sure at the moment if this is arising from Labview or some other configuration.

[rolfk]

If you use LabVIEW 2018 and the according HTTP Client library that comes with it and haven't upgraded the HTTP Client library itself separately, you definitely won't gain anything by trying to add the certificate to the Windows certificate store. libcurl included with LabVIEW versions before around 2021 use not only a rather old version of libcurl but also a rather old version of openssl that has no idea about the Windows certificate store and only works with the ca_bundle file, or on non-Windows systems also with the local file-store of certificates.

Somewhere in recent versions of the HTTP Client library they did update the libcurl version that also uses more modern openssl for the encryption features. However I'm not sure if and where they would have moved to the new 3.2 openssl version (most likely not yet). That is basically the first that by default supports use of the Windows certificate store instead of the ca_bundle file.

The native TSL support in LabVIEW TCP functions has since around 2022 some extra custom implemented Windows certificate store verification around the underlying openssl functions that they use for the TSL support.

I have been able in the past to upgrade the NI OpenSSL and NI LibCurl packages seperately to newer versions "borrowed" from later LabVIEW versions to make the HTTP Client library work with some WebAPI service that we had used in the ERP system back then. That was however for a tool compiled in I think LabVIEW 2013 and I had to upgrade the HTTP Client runtime support to LabVIEW 2018 or thereabout for it to work.