Jump to content
JackDunaway

LabVIEW could not verify the authenticity of the server

Recommended Posts

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.

 

post-17237-0-05827500-1361739027.png

 

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!

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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-----
 

post-17237-0-26993500-1368221835.png

 

  • Like 1

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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 by ShaunR
  • Like 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.