Mark Yedinak

Ok, I realize it has been a while. I had to put this on the back burner for a while. Anyway, I finally resolved the problem. Turns out that the key file was encrypted and the application web server couldn't read it. I had to do various conversions using openssl so I could get a key file that was not encrypted. Now it is finally working. It had been a couple of years since the last time I did this and I had forgotten that crucial piece of information. What a pain in the butt.

Yes. The entire process I used to create the CSR and get the certificate was the same. I used OpenSSL to generate the CSR, sent that to my CA (same as before) and got the new certificate. I followed the steps in the KB I linked earlier and so far nothing has worked.

Yes, it is the key used for the CSR to generate the certificate.

Yes, it was in the same folder as I am putting the new certificate in.

Well the error is not very detailed. The previous certificate that worked was from the same certificate authority and the info was the same. I'm still trying to find the magic combination to get the application web server to accept the certificate.

This is the error log I am seeing: appweb: Error: OpenSSL: Cannot define private key file: C:\ProgramData\National Instruments\certstore\server_certs\server_0.key I am trying to add my external certificate. I had done this a couple of years ago but forgot the exact combination of steps that worked back then. I have tried creating a CSR from the web server config and then adding my certificate as the correct certificate. This hasn't been working. I also tried to replace the self signed certificate with mine. This is very frustrating. As I did mention, the certificate itself is fine. It works for the NI Web Service as well as for an apache server running on a Linux machine. I just can't get the Ni Application Web Server to use it.

The NI Application Web Server. I specified that in my original post. No, there is nothing in the trace. I finally found some log information. I was looking in the Program Files (64 bit) shared folder but the logs are actually in the 32 bit folder. I am getting an error opening a certificate that is in the certstore folder but is not actually referenced anywhere. I think this may be the issue and I will dig into this some more. This particular application is still on LabVIEW 2018. I know that there have been some improvements with respect to certificates in more recent versions but at the moment I cannot update.

I have an externally signed certificate for TLS that I am trying to install to replace an expired certificate. I have followed the process described here. Everything appears to work but when the application web server is restarted so it will pick up the new certificate I see that the certificate has disappeared. The files are still there but when looking at the application web server info in the ancient Internet Explorer interface the certificate is gone. I have enabled logging for the application web server but I never see any entries in the log file. This had worked in the past but now nothing is working. BTW, the certificate works fine as the NI System Web server uses it and everything works as expected. The certificate is also used on a different Linux based web server (it is a wildcard certificate for my domain). I would like to get this certificate installed and working. Anyone have any suggestions? I should also note that in the race instances that the certificate still appears in the Ni Application Web Server configuration (via the Internet Explorer interface) any attempt to invoke a connection using TLS is rejected immediately. A trace using Wireshark shows the connection is accepted and the Client Hello message is received from the client then the connection is immediately closed with a TCP-RST by the server. All of this had worked properly in the past. The only difference is that I am installing a new certificate since the old one expired. This certificate is valid since it works with the NI Web Server as well as a Linux based Apache server.

I took a look at JSON and I definitely like it better than XML. The problem in this particular case is that I will have binary data as part of the data set and JSON doesn't look like it supports that very well. I will probably just define the data format using a basic C style structure and decode/encode it in LabVIEW.

Is the variant data type well enough defined that a specification can be given to programmer's using another language that they could decode/encode variant data? I am working on a messaging interface that will pass messgaes between LabVIEW, Python and possibly C/C++. Obviously within LabVIEW variants are a very convenient way to pass generic data around at the lower levels of a messaging API. However, the format of the data when flattened to string to pass over TCP connectons is rather daunting. Is my best option to change my lower level code to use a more conventional and defined data structure (basic a simple stream of bytes) and then parse that ino meaningful constructs in LabVIEW? That is, where I currently have variants should I replace them with a string and then at the appropriate places decode that into a cluster. Taking this approach would allow me to define C style structures which can be easily read/transmitted in other languages.

Count me in. Just bought my ticket. And you can tick the CLA count too.

No, The data collection loop is running at a whopping 1 sample per second. The display and logging tasks are driven by the collection tasks. That is what is so baffling about this leak. This application is running at a very slow pace and to see the increase in handles and memory over a short period of time is quite surprising. I will be digging into this more later. I don't think I'll get a chance to work on it today though. Thanks to all for the suggestions.

OK, I haven't broken the application down into the component parts yets but did rebuild it on my local machine (this application actually runs at a client site) and monitored it overnight. The memory is slowing increasing and the stats from perfmon shows that the handle count is extremely high. The handle count was well over 7000000 after about 6.5 hours of running. The memory size was 5 times greater than when the application started. It is colecting the data from a remote site using HTTP once per second. It then logs that same data into a DB. Both the HTTP connection and DB connection are left open. Does the extreme handle count provide any clues where to look. I will break it into three separate applications for test purposes but thought the handle count may point to a specific area.

And no, no DLL's that I know of. If the password protected stuuf is calling something though I would have no way of knowing.