LabVIEW could not verify the authenticity of the server

[JackDunaway]

Attempting to connect over HTTPS to a web service written in LabVIEW, I get the following error:

 

Error 363507 - LabVIEW could not verify the authenticity of the server

 

Shown below, this code demonstrates the issue. The 'workaround'? Set the 'verify server' flag to false.

 

 

Shown at the bottom is a simple HTTPS connection to Google works no prob -- could this indicate a misconfiguration on my web service?

 

Any ideas? Thanks!

[JackDunaway]

Sleuthing a bit further with Wireshark:

 

It appears that the final SSL transaction from LabVIEW to the Web Service is: TLSv1 Record Layer: Alert (Level: Fatal, Description: Unknown CA)

 

Where does LabVIEW get its list of known/trusted Certification Authorities? This appears to be my problem.

[ShaunR]

You can create your own "self, signed" certs or you can use a free service. However. If you are going "public" and it will be used for commerce you really, really (can't enphasis enough.......REALLY) should buy one from a trusted CA

[JackDunaway]

You can create your own "self, signed" certs or you can use a free service. However. If you are going "public" and it will be used for commerce you really, really (can't enphasis enough.......REALLY) should buy one from a trusted CA

 

Yep; I'm a little ahead of you here; sorry for not giving all the details.

 

I have already set up the web service with a cert from a trusted CA (it's one shown in the Trusted Root Certification Authorities using the Certificates snap in on mmc.exe).

 

When accessing the web service from a browser; no problems. Green lock and everything (in Chrome). When accessing from LabVIEW -- "LabVIEW could not verify the authenticity of the server".

 

I have a hunch this could be because the cert is 2048-bit; the one from Google that LabVIEW likes/accepts is 1024-bit. I have not yet been tempted to re-key the service at 1024-bit, because i've found it's a bit cumbersome to install a 3rd-party CA cert using the Web Services configuration panel. Additionally, i have verified with Wireshark that even when LabVIEW is configured with "verify server=FALSE", the connection proceeds no probs with SSL encryption -- which somewhat lessens the severity of this issue, but I still would like to find the correct workaround.

[Rolf Kalbermatter]

Yep; I'm a little ahead of you here; sorry for not giving all the details.

 

I have already set up the web service with a cert from a trusted CA (it's one shown in the Trusted Root Certification Authorities using the Certificates snap in on mmc.exe).

 

When accessing the web service from a browser; no problems. Green lock and everything (in Chrome). When accessing from LabVIEW -- "LabVIEW could not verify the authenticity of the server".

 

I have a hunch this could be because the cert is 2048-bit; the one from Google that LabVIEW likes/accepts is 1024-bit. I have not yet been tempted to re-key the service at 1024-bit, because i've found it's a bit cumbersome to install a 3rd-party CA cert using the Web Services configuration panel. Additionally, i have verified with Wireshark that even when LabVIEW is configured with "verify server=FALSE", the connection proceeds no probs with SSL encryption -- which somewhat lessens the severity of this issue, but I still would like to find the correct workaround.

 

LabVIEW's HTTPS support uses most likely OpenSSL for the SSL implementation. OpenSSL comes with it's own list of Root CA and does AFAIK not try to access any platform specific CA stores. As such the only options for self signed server CAs is to either skip the verification of the server certificate or to try to import the self signed certificate into the session. I think the SSL.vi or Config SSL.vi should allow to do that.

[JackDunaway]

LabVIEW's HTTPS support uses most likely OpenSSL for the SSL implementation. OpenSSL comes with it's own list of Root CA and does AFAIK not try to access any platform specific CA stores. As such the only options for self signed server CAs is to either skip the verification of the server certificate or to try to import the self signed certificate into the session. I think the SSL.vi or Config SSL.vi should allow to do that.

 

Rolf; thank you for this reply. To follow up, I have received some ideas through another channel on how to solve this issue; I will report back after testing the suggestions. (Having just concluded the CLA Summit, I will be back on this project soon). Brief spoiler -- this channel's suggestions are not unlike yours.

[JackDunaway]

LabVIEW's HTTPS support uses most likely OpenSSL for the SSL implementation. OpenSSL comes with it's own list of Root CA and does AFAIK not try to access any platform specific CA stores. As such the only options for self signed server CAs is to either skip the verification of the server certificate or to try to import the self signed certificate into the session. I think the SSL.vi or Config SSL.vi should allow to do that.

 

Everything works now, here's what I've learned: LabVIEW is using a list of trusted authorities from the file: "%ProgramFiles%National InstrumentsSharednicurlca-bundle.crt"

 

If your Certificate Signing Authority is not in that list, you will receive Error 363507 - LabVIEW could not verify the authenticity of the server.

 

In order to avoid this error, either find a new Certificate Signing Authority, or you can specify your own Trusted Certificate Authorities using ConfigSSL.vi (shown in the screenshot below). When you distribute your application, ensure to include this file with the distributable.

 

When you download your certificate from your CA, through the management console you can probably also download the Root Certificate of the CA -- this is the file that you wire into CA certificate file of ConfigSSL.vi. (This file might even be included as a zipped certificate bundle when you download your cert.) This file will look like the following if opened in a text editor:

 

 

-----BEGIN CERTIFICATE-----

MIIFB...LinesAndLinesOfBase64....==

-----END CERTIFICATE-----

 

-----BEGIN CERTIFICATE-----

MIIED...LinesAndLinesOfBase64....==

-----END CERTIFICATE-----

 

 

[chwang]

Could you tell me how do you generate the TrustedCA.crt. I use keytool.exe to create a *.cer file for the server and pass it to ConfigSSL.vi, but I always get an error:

 

 

Error 363507 occurred at LabVIEWHTTPClient.lvlib:GET.vi:1
Possible reason(s):
LabVIEW:  LabVIEW could not verify the authenticity of the server.

 

Could you tell me how to generate the TrustedCA.crt for ConfigSSL.vi?

[kingcobraninja]

I'm seeing this issue.  Did anyone ever figure this out?

[infinitenothing]

Are you setting verify to "false"? The verify server input is for using client certificates. I don't think you need it if you are connecting to a public site. I believe in that case, the function will verify with public CAs instead of using your client cert.

[ShaunR]

1 hour ago, infinitenothing said:

Are you setting verify to "false"? The verify server input is for using client certificates. I don't think you need it if you are connecting to a public site. I believe in that case, the function will verify with public CAs instead of using your client cert.

Setting "Verify" to false just turns off the certificate check so that any old certificate is accepted without error. This is of course a security risk and should never be used outside of development.

IIRC. The LabVIEW HTTP functions use cURL and the "ca-bundle.crt" located in \National Instruments\Shared\nicurl. It contains the certificates of the Authorities. Adding the servers' certificate or the servers' trusted root certificate to that list once you have ascertained the certificate is correct for that website; is the recommended procedure for adding ad-hoc certificates (thus keeping "Verify" = True).

Edited April 9, 2019 by ShaunR