Installing third party certificate for NI Application Web Services

[Mark Yedinak]

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.

[JKSH]

4 hours ago, Mark Yedinak said:

NI Application Web Server

Which one? NI has a few different web servers: https://forums.ni.com/t5/SystemLink/Relationship-between-quot-NI-Web-Server-quot-quot-NI-System-Web/td-p/3662789

If you're using the new "NI Web Server" rather than the old "NI Application Web Server", try asking at the SystemLink forum.

[ShaunR]

9 hours ago, Mark Yedinak said:

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.

Is there no "Alert" before the RST?

[Mark Yedinak]

10 hours ago, JKSH said:

Which one? NI has a few different web servers: https://forums.ni.com/t5/SystemLink/Relationship-between-quot-NI-Web-Server-quot-quot-NI-System-Web/td-p/3662789

If you're using the new "NI Web Server" rather than the old "NI Application Web Server", try asking at the SystemLink forum.

The NI Application Web Server. I specified that in my original post.

5 hours ago, ShaunR said:

Is there no "Alert" before the RST?

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.

[ShaunR]

1 hour ago, Mark Yedinak said:

I know that there have been some improvements with respect to certificates in more recent versions but at the moment I cannot update.

Well. LabVIEW 2022 is shipped with OpenSSL 1.0.2u  20 Dec 2019 so don't get your hopes up. That said; if it's an RSA or EC certificate you should be fine. I would be looking at other issues especially as there was no Alert complaining about the certificate or ciphers.

Edited September 2, 2022 by ShaunR

[Mark Yedinak]

1 hour ago, ShaunR said:

Well. LabVIEW 2022 is shipped with OpenSSL 1.0.2u  20 Dec 2019 so don't get your hopes up. That said; if it's an RSA or EC certificate you should be fine. I would be looking at other issues especially as there was no Alert complaining about the certificate or ciphers.

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.

 

Edited September 2, 2022 by Mark Yedinak

[ShaunR]

55 minutes ago, Mark Yedinak said:

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.

 

It's not something silly like it can't handle spaces in the path, is it?

[Mark Yedinak]

1 hour ago, ShaunR said:

It's not something silly like it can't handle spaces in the path, is it?

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.

[ShaunR]

1 hour ago, Mark Yedinak said:

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.

Yes. But was it in the same location? "National Instruments" has a space in it. Try it in a short path without any spaces like c:\tmp. Try the simple stuff first.

[Mark Yedinak]

1 minute ago, ShaunR said:

Yes. But was it in the same location? "National Instruments" has a space in it. Try it in a short path without any spaces like c:\tmp. Try the simple stuff first.

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

[ShaunR]

4 hours ago, Mark Yedinak said:

appweb: Error: OpenSSL: Cannot define private key file: C:\ProgramData\National Instruments\certstore\server_certs\server_0.key

Hang on. That error seems to be saying it requires the private key. The certificate from the CA is a signed version of that private key's public key.

Is that "server_0.key" the private key that you used to generate the Certificate Signing Request (CSR) for the CA?

Edited September 2, 2022 by ShaunR

[Mark Yedinak]

4 hours ago, ShaunR said:

Hang on. That error seems to be saying it requires the private key. The certificate from the CA is a signed version of that private key's public key.

Is that "server_0.key" the private key that you used to generate the Certificate Signing Request (CSR) for the CA?

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

[ShaunR]

8 minutes ago, Mark Yedinak said:

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

In PEM format?

[Mark Yedinak]

On 9/2/2022 at 8:41 PM, ShaunR said:

In PEM format?

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.

[ShaunR]

I'll preface this with "I have never used that software" and I don't know of any standard fixes. I would be putting on my Sherlock Holmes hat and taking a big toke on the Meerschaum. Maybe someone else has a standard fix but this is how I would approach it...

First I would check that the new server.key and certificate format is the same as the old one (probably PEM but just could easily be DER). It's easily done just by opening in a text editor. Jibberish is DER. PEM is "-----BEGIN CERTIFICATE----" (maybe this software only supports one format). Same for the private key - which would be gibberish or something like "-----BEGIN RSA PRIVATE KEY-----".

Then I'd create a self-signed certicate and load that with it's key to see if the software had the same complaint.

Then I would be taking a closer look at the new certificate and the old one and see what's different about the new one - paying particular attention to the type of Public Key, the Key Extensions and the signing method. (if there is no TLS Webserver 

Then I would check that the public key of my private key matches that in the certificate.

The above would mainly be to verify that the certificate is indeed for the key I think it is for, and that the private key is the same/similar type to that which was used previously. If they are not the same type then I would generate a self signed certificate with the new type and see if I again get the error. Note that this is before we get to what the CA has done so buckle up or use some other software 

Here is googles cert and what I'd be looking at on the first pass.

 

Edited September 6, 2022 by ShaunR

[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.