10-18-2019 12:36 AM
Hi,
I am using Labview 2013 HTTP GET to retrieve info from an online amazon cloud service database. I repeatedly keep getting Error 363507 - Labview Cannot Verify Server Authenticity. When I wire up HTTP GET to Google, I do see a return. But, when I switch back to the online cloud database, I get Error 363507. I thought that it may have something to do with my Windows 7 computer so I wrote a python script to contact the database and retrieve info and it worked. Has anyone experienced anything like this? Any suggestions on why I am getting Error 363507 when I try to contact the cloud database using HTTP GET?
10-18-2019 01:40 AM
@BHelang wrote:
Hi,
I am using Labview 2013 HTTP GET to retrieve info from an online amazon cloud service database. I repeatedly keep getting Error 363507 - Labview Cannot Verify Server Authenticity. When I wire up HTTP GET to Google, I do see a return. But, when I switch back to the online cloud database, I get Error 363507. I thought that it may have something to do with my Windows 7 computer so I wrote a python script to contact the database and retrieve info and it worked. Has anyone experienced anything like this? Any suggestions on why I am getting Error 363507 when I try to contact the cloud database using HTTP GET?
Did you have a fix on this issue? I have the same problem.
10-18-2019 01:51 AM - edited 10-18-2019 01:56 AM
LabVIEW HTTP Client VIs are using curl internally which then uses an NI version of OpenSSL for HTTPS socket encryption. OpenSSL does not connect to the native Windows certificate store but instead comes with its own root certificate store. LabVIEW 2013 being already 6 years old has a good chance to install an outdated certificate store for modern cloud services so that their SSL certificate can’t be verified with the outdated root certificates.
Since the NI certificate store is at the same location for all LabVIEW versions installing a recent version would fix that.
You could also try to replace the file at
C:\Program Files (x86)\National Instruments\Shared\nicurl\ca-bundle.crt
with a more recent version from either a new LabVIEW installtion or maybe directly from the OpenSSL project.
10-18-2019 01:00 PM
Hi,
This is what I received:
LabVIEW HTTP Client VIs are using curl internally which then uses an NI version of OpenSSL for HTTPS socket encryption. OpenSSL does not connect to the native Windows certificate store but instead comes with its own root certificate store. LabVIEW 2013 being already 6 years old has a good chance to install an outdated certificate store for modern cloud services so that their SSL certificate can’t be verified with the outdated root certificates.
Since the NI certificate store is at the same location for all LabVIEW versions installing a recent version would fix that.
You could also try to replace the file at
C:\Program Files (x86)\National Instruments\Shared\nicurl\ca-bundle.crt
with a more recent version from either a new LabVIEW installtion or maybe directly from the OpenSSL project.