SSL Certification and LabVIEW

[ogk.nz]

So I have just come upon an interesting issue which may cause significant problems unless I can find a reasonable solution.

Up until yesterday a number of software programs that are running in a number of remote locations were all running happily accessing a database.  This database is accessed through the HTTPS POST and HTTPCLIENT VIs, and for the past couple of years everything has been running nicely while having the verify server flag true, the database is part of a corporate site that is all properly signed and certified.

However, as of yesterday they all decided to stop, from investigating into the server itself it appears that the SSL certificate has rolled over from its previous period. By looking around the LAVA forums I managed to find reference to the problem being an the LabVIEW ca-bundle.crt file being outdated so not properly checking the validity of the new certificate.

Now while there is a workaround here that switching the verify server flag from TRUE to FALSE I can make all the programs work again, there remains the significant issue of having to update and rebuild several years worth of programs. So I was hoping for something that I could do outside of LabVIEW to try and resolve the problem, I had considered replacing the ca-bundle.crt but I am not sure of the validity of this idea.

So any ideas are likely to be accepted if they mean I don't have to go back over several versions of LabVIEW.

TLDR:

Can I do anything with this to solve the problem?

[rolfk]

I'm afraid that safe from replacing the ca-bundle.cert file there is nothing you can do without changing the software. Please also note that disabling the SSL certificate error is only a real option if you are sure that your network is private and doesn't have any connection to the outside world. Otherwise disabling that is a serious security hazard.

The LabVIEW HTTP VIs make internally use of a an OpenSSL or similar infrastructure that is completely independent of the Windows crypto and certification infrastructure. As such it can not benefit from the automatic updates to those certificates but relies on its own ca-bundle.cert file database. As you have found out, that can have some drawbacks but the advantages of not relying on the Windows infrastructure has its roots in the fact that LabVIEW (and the HTTP client VIs) are multiplatform and must run on MacOSX, Linux and the NI realtime targets too.

Aside from making sure to update the certification database file you might also call in with NI and request an official support ticket. It will likely not give you an immediate solution but this file should be part of what the NI Software Update utility does update. You do have that active don't you?

To summarise, disabling the SSL security check is only the last resort if anything else fails and should never be considered on a network for which you do not know for a fact that it is really safe and private.

[Sam_Sharp]

Can't you specify the certificate to use for validation using the Config SSL.vi in the HTTP toolkit? My understanding was that this would allow you to supply your own certificates to use for verifying the server instead of using the LabVIEW default ones?

[rolfk]

---

@Sam_Sharp wrote:

Can't you specify the certificate to use for validation using the Config SSL.vi in the HTTP toolkit? My understanding was that this would allow you to supply your own certificates to use for verifying the server instead of using the LabVIEW default ones?

---

That still requires to go back into the LabVIEW sources and modifying the VIs to add explicit SSL certificate configuration. It's definitely better than disabling the SSL certificate verification but not a fix that can be done without changing the LabVIEW programs in the source code either.

[ogk.nz · Accepted solution]

Welll the good news is that I have found a solution. The problem is that I am not sure how far this solution is going to get me, it should at least mean I can reach the single database I am targeting.

By following backwards from the database certificate provider (COMODO) I found that they provide a certification authority bundle which when used to replace the LabVIEW supplied ca-bundle.crt allows the HTTP system to access the database without issue.

For the remote computers this is probably fine as it is guaranteed that the only SSL secured site that they are going to be trying to access will be the database who I know the data is compatible with. For my development system however this might still remain a problem as I am not sure when I will need to try and access another certified site and whether or not the new authority will work. Although in fairness for now I am not sure whether the LabVIEW provided one will work either.

I may have to come back to this thread at a later date and provide an update on how everything has worked out.

[rolfk]

Just to be complete. You may want to look at this. It details a pretty easy way of updatig the NI provided ca-bundle.crt file with additional certificate entries if you have a specific server you want to be autentificated with the LabVIEW HTTP Client VIs.

[FixedWire]

Thank you Rolf for all your input on this topic over the years!

Does anyone know how to ensure the certificate(s) are registered correctly on Windows 10?

We've got the webservice working using SoapUI & can't find where were the difference is.

We've also tried adding in the certs using ConfigSSL.vi as well as adding the certs to the LabVIEW cert buried in Program Files and are now hitting a wall.

Any suggestions are appreciated.