Impact of “AutomaticallyTrustAllClientCertificates” on Message Encryption

Unified Architecture topics related to OPC UA Specification, compliant behavior and any technical issues of OPC UA, like Security, Information Model, Companion Specs DI, PLCopen, ADI, ...

Moderator: Support Team

Post Reply
luna1111
Jr. Member
Jr. Member
Posts: 1
Joined: 10 Jan 2024, 09:10

Impact of “AutomaticallyTrustAllClientCertificates” on Message Encryption

Post by luna1111 »

Hi,
I am currently looking into "AutomaticallyTrustAllClientCertificates".
I understand that if I set this value to "True", all client certificates are automatically trusted.
In this case, what about message encryption?

In my understanding, a client's public key is included in the client's certificate.
And the server get the client's public key when exchanging their own certificate.
Then the server responde message to the client is encrypted with the client's public key, and the client decrypts it with its private key to read.

However, if "AutomaticallyTrustAllClientCertificates" is set to "True", the server cannot use the client's public key and encrypto, is it correct? So the response from the server will be in plain text?

Thanks in advance.

User avatar
Support Team
Hero Member
Hero Member
Posts: 3073
Joined: 18 Mar 2011, 15:09

Re: Impact of “AutomaticallyTrustAllClientCertificates” on Message Encryption

Post by Support Team »

Hi,

the public key exchange is done in a first step, thereafter you must "trust" on both sides in a second (typically manually) step. Some "admin" must check the certificate and decide to "trust" the opposit. Thereafter the public key is used to encrypt and te private key is used to decrypt.

The "AutoTrustAll" switch should NOT be used, because it will make the server to allow all clients to connect, without any person to check and decide. Such switch litterally switches off the certificate validation on the server-side of the communication, and is typically used by headless servers, who have "public" information only. Therefore, you better NOT USE and forget about this switch because it weakens the security.

The much better (and intended) alternative is: if you need automatic trust on headless devices, you MUST USE the CA (certificate authority). In a first step the CA "signs" all the certificates of the allowed communication partners, and in a second step you just trust the CA on both sides (and by this every cert that was issued by this CA). By doing so you will also have "automatic" trust, but only for allowed (signed) communication partners.

Check out "UaGDS" on our download page, which is CA exactly doing the above.
https://www.unified-automation.com/downloads/opc-ua-servers.html

In any case the exchanged public key is used for encryption, there is no "plain text" (un-encrypted) messages being exchanged (except you use the "None" security policy, which is the worst from a security standpoint)
Best regards
Unified Automation Support Team

Post Reply