Search the Community

Hello, I'm trying to run a LabVIEW web service using the HTTPS protocol. I have published my webservice on a windows server. I tested with another machine (client) this webservice and all works correctly. Then I wanted to enable HTTPS on the web service, so I created a self-signed certificate configured with the server's IP address, which I installed on the server and the client machine (my computer). On the client side, I manage to go through the server, but an error message tells me that it can't find the url of my web service method. It's as if my web service didn't exist, but it works if I use HTTP. Below are the images of my web service configuration : I'm also displaying the error I get when I make the request: Thank you in advance for your reply.

Hello all, I am currently trying to create an HTTPS server with LabVIEW. I have been using the built in TCP VI's for communication with the server and client, however I would like to use SSL or TLS in order to encrypt the data that is being sent across the connection. I know that I can point to either the self-signed cert that comes packaged with LabVIEW, or the certificate that we have for our server on-site. I'm fairly certain that I can achieve this by building an assembly in .NET, and then using it in LabVIEW. I have looked around for TCP with TLS libraries for LabVIEW but could only found some out-of-date ones that didn't work with the newest version of LabVIEW. Do these libraries exist somewhere? And if not, is the .NET approach a solid idea? Thanks, Brandon Jones

Ok anyone who can manage to contain their laughter for a minute, help me out with this. I need exactly what's in the title. Due to the deprecation of TLS1.0 and SSL3, we're disabling both on our web server that receives status information from hundreds of systems across the country via HTTPS. Some of the systems run Windows 7, some Windows XP. All of them run applications built in LV 2012sp1. In the past we've used the NI HTTP client VIs, which work well, and still work for some (?) Win7 systems. They don't work for the Windows XP systems. Are these VI's just a wrapper for the OS's HTTP client (IE)? We've also been down the .net WebRequest path, but from what I can tell the webclient class doesn't support any security protocols past TLS1.0, at least not in .net 2.0, and the HTTPClient class wasn't introduced until .net 4.5, which LV doesn't support, at least not in 2012 sp1. Lastly, we're considering the Encryption Compendium being offered in the JKI package manager, but it's 629 pounds, and if there's a way to do this without it, it would be preferred. Also we're not sure it would work with the given constraints. Has anyone used it/know anything about it? Any help is appreciated.

In this topic I was helped to understand how to use the HTTP Client VIs to connect to a HTTPS server. I have manged to use those Client VIs to gather sufficient (dynamic) information from the server to form the dynamic download links for a series of CSV data files that the server can provide. The HTTP Client VIs seem to me to be able to only return web page header and body information. I have not found a way to use them to grab a file specified by a URL. Is there a way to do this with them? The HTTP Client VIs make use of "Client Handle" RefNums to identify the open connection. Are there other VIs available in the VI library that can also use these same Client Handles and which can transfer a file? Thanks!

I am trying to use the HTTP Client VIs to implement a version of the C# code found HERE. Unfortunately there are no NI examples of how the client VIs are to be used and my various attempts to string them together only seem to result in "Error 42" (LabVIEW: Generic Error) from the POST vi, rather than returning the headers and body text. I have also tried using DOTNET calls and was at least able to get the login page returned but could not seem to trigger the login. I switched to the HTTP Client VIs because they offered an alternate hope and I could at least see where to attach a cookie file with them (though a cookie file may not be the same as reserving space for a session cookie). Any guidance would be appreciated!