search

mikakaraila / node-red-contrib-opcua

A Node-RED node to communicate OPC UA. Uses node-opcua library.
Other
212 stars 196 forks source link

Certificate names can no longer be freely selected and the path setting does not work #664

Closed Eldarion85 closed 7 months ago

Eldarion85 commented 7 months ago

Hi @mikakaraila, a separate PKI certificate-path and certificate-name no longer works. Until a few versions ago, you could still specify the path of the PKI order in the settings for the OPC client and that worked. After switching from openssl to built-in crypto, we were no longer able to connect with certificates last year (see #577).

You suspected the problem was in the node-opcua/node-opcua-crypto and I went to look for it with @erossignon in a video call. We found the problem. It was because the PKI-folder was no longer allowed to have its own path and the path "~/.config/node-opcua-default-nodejs/PKI" had to be used. Etienne wanted to discuss this with you.

That was enough for us at the time. However, I now had to create new certificates because the validity has expired. I encountered strange behavior again.

You have now removed the setting for your own PKI-folder. That's why I assume that you won't be able to use your own PKI-path in the future and that the path "~/.config/node-opcua-default-nodejs/PKI" will remain. Nevertheless, there are still two settings for the absolute path to the certificate and the private key. I named the certificate "client_certificate.pem" and the key "private_key.pem" with Etienne and then didn't test it any further.

Our certificates in the company have defined names and we don't want to call them that. So I copied the new couple into the folder and stored the two names in the client node.

After deploy there is no error at first. But the connection is not established. rightPath

In order to check whether my certificates are being used at all, I specified an incorrect file. After deploy, this will also be displayed correctly. wrongPath

I then specified the correct path again and, although the connection was not established, I gave a trigger (read) to the node. Then the debug suddenly showed me that the file “client_certificate.pem” must exist. I'm confused, why does the file have to exist when there is an extra setting for its own name in the node? ownName

Then I named the certificate "client_certificate.pem" and the key "private_key.pem" and the connection was established immediately. For fun, I entered both files incorrectly. The error then occurs that the files do not exist. But since the connection isn't interested in the paths specified there anyway, it still works. sessionActive

This behavior doesn't make any sense, does it? It's okay that the PKI path can no longer be freely specified. But why can't you even determine the names of the certificates and keys anymore? In our company we don't want to name the files client_certificate and private_key, but we don't have any other option at the moment. We use hundreds of applications with certificates and we can freely assign names everywhere. Why are there two settings for this in the node if they are not used? In addition, the messages in the debug make no sense because they show that I have specified an incorrect file, but in the background the files client_certificate and private_key are simply used.

Many thanks for the support!

mikakaraila commented 7 months ago

Yes, I know that this was breaking change. I am again longer sick leave so I cannot promise anything at the moment. But when I feel better I will take a look to add some option to use own file names (hopefully). Certificate manager creates normally all needed files etc. for the PKI.

Eldarion85 commented 7 months ago

We have our own public key infrastructure with root CA and several intermediate CAs. This is not just for OPC, but all connections in the company. We therefore cannot simply create the certificates with the integrated manager. Basically, that's how it works if you know what the problem is. I hope you get well again soon. Thank you for this fast answer.

Eldarion85 commented 7 months ago

If you feel better and get around to fixing it, you might also want to look at the name of the connection.

Before switching to build-in-crypto, the name given to the node was sent to the server as a client name. clientName

This made it easy to monitor the connections in the server (S7-1516) and evaluate exactly which connection was causing problems. Since the change, unfortunately only "ClientSession1" is displayed in the server for all connections and automatic evaluation no longer works. That would also be an important update for the future. sessionName

Thank you very much and get well soon!

mikakaraila commented 7 months ago

Ok, feeling bit better. At least sessionName is back from the node name: image

mikakaraila commented 7 months ago

I studied certificate Manager interfaces and it uses default internal names for the files. So it is not possible to set those from the client node anymore... I will disable fields from the UI. Sorry, I know that this has broken part of the earlier functionality.

Updated UI (not the best solution but tells enough): image

Eldarion85 commented 7 months ago

Ok, feeling bit better. At least sessionName is back from the node name:

Hello, I'm glad to hear that. Thank you for the improvement! I'll try it out as soon as I see the update in Node-RED. Currently 0.2.321 is the most current version.

Eldarion85 commented 7 months ago

I studied certificate Manager interfaces and it uses default internal names for the files. So it is not possible to set those from the client node anymore... I will disable fields from the UI. Sorry, I know that this has broken part of the earlier functionality.

Thank you very much for the information. However, it doesn't really make sense to deactivate the fields. The fact that the PKI folder is no longer freely selectable is not a problem and perhaps a good thing. But as I already wrote above, it is very bad if the keys now have to be called "client_certificate" and "private_key". We have defined names for all certificates in the company and that would not be practical. If @erossignon would implement this, you could design your fields so that you can only enter the certificate name. The path can and should remain firmly defined (PKI/own/certs and /private), only the name of the two keys must remain flexible.

Eldarion85 commented 7 months ago

I'm already writing with Etienne. If you simply lock the fields now, it would be extremely bad for functionality.

The problem is not the renaming. Previously, you could specify different certificates for the different OPC clients. This is very important when they communicate with different OPC servers and they are not all allowed to get the same root CA and intermediate CA that they trust. If all OPC client nodes can now only use the same certificate, the entire secure concept that was previously possible is no longer possible.