Server Settings (Security, Authentication)

[aass9531]

I am trying to connect to the Demo Server by executing uaservercpp.exe in the SDK Bundle (Unified Automation UA ​​SDK C++ Bundle 1.5.4 (SOURCE Edition)) using the security options. Please check if my understanding of the procedure is correct and answer any questions. .

1. I want to use the server security option.
Security Policy: Basic256Sha256
Message Security Mode: Sign & Encrypt



2. To enable the server security option, I used UaExpert's Application certificate (C:\Users\User\AppData\Roaming\unifiedautomation\uaexpert\PKI\own\certs).
I copied and pasted the uaexpert.der file into the “uaexpert.der” path on the Server: “C:\ProgramData\UnifiedAutomation\UaSdkCppBundleSource\pkiserver\trusted\certs.” (Refer to ServConfig.xml.)



Q1. Are the certificate management procedures related to Security Policy and Message Security Mode completed in steps 1-2? Or is there an additional process? Is a private key used in this process?

3. I want to use Authentication Settings.
I'm trying to use the Cert/Private Key method.
The certificate used the uaexpert.der file in C:\Users\User\AppData\Roaming\unifiedautomation\uaexpert\PKI\own\certs on the client.
Private Key is the client's
I used the uaexpert_key.pem file located in the path C:/Users/User/AppData/Roaming/unifiedautomation/uaexpert/PKI/own/private/.



4. I copied&paste the uaexpert.der file to pkiuser on Server.



5. Connection was successful.
But I did not copy the uaexpert_key.pem file to "server\pkiuser".

Q2. What exactly does the private key registered in Server Settings do?
Please tell me exactly how to use Authentication Settings.


Thank you for your attention to this matter.

[Support Team]

Hi,

please make yourself familiar with asymetric key exchange, and PKI concepts !!!

Fist of all: you never ever, under no cricumstances at all, never at no times, never ever touch the private key !
-> the idea behind it's name containing the word "private" is: THAT IT IS PRIVATE !

secondly, the public-key is the key that gets exchanged automatically in the OPC UA protocoll connection establishment procedure ! You do NOT need to do anything for it, it is done AUTOMATICALLY.

third, both the applications (client AND server) must verify the public-key/certificate of the counterpart (both sides, crosswise, vice versa). Such verification is done for technically correctness AND for the basic question of being known/allowed/trusted. Only after positive verification they finally establish the communication connection. This last check, the TRUST-check, is done by the application by looking into the application's PKI "trust" store and check for existence of the counterpart's certificate.

fourth, how is the certificate getting to become "trusted"? In some OPC UA application (mainly those that have no fancy GUI for configuation like UaExpert asking the user for "trusting" the conterpart's certificate) this manuall step of "trusting" is done by some local administrator manually checking the content of the certificate for plausibility, and if satisfied, moving the (in step 2 already automatically received, but quarantained) certificate form the "rejected" to the "trusted" folder in the application's PKI store. However, must "trust" crosswise on BOTH sides.

This manual step of "trust" the conterpart's certificate is only needed the very first time this two appliactions try to connect. Thereafter they "trust" eachother and will establish the connection without any manual interaction.

ADDITIONALLY, some applications allow for "User Authentication", whereas the server (the owner of the data) may have a list of differnet users in different roles, that he is going to allow access to some certain datapoints or operations. Most servers allow "anonymous" (guest-) access to their data. If supported by the server such "users" can identify themselves by username or by user-certificate, or some other user-token. The server must support some configuration for "some users (joe, sue, paul) are containd in group/role (guest, operator, admin) and the role "admin" is allowed for writing to NodeID xxx.