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.
Impact of “AutomaticallyTrustAllClientCertificates” on Message Encryption
Moderator: Support Team
-
- Jr. Member
- Posts: 1
- Joined: 10 Jan 2024, 09:10
- Support Team
- Hero Member
- Posts: 3074
- Joined: 18 Mar 2011, 15:09
Re: Impact of “AutomaticallyTrustAllClientCertificates” on Message Encryption
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)
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
Unified Automation Support Team