Hi,

Most clients and servers do not support opc.https. Best would be to not enable it if there is an option and also ignore it even exists. Most interop testing is just done using opc.tcp.

The opc.tcp protocol doesn’t use TLS, the security (sign+encryption) is defined within OPC UA Specification (i.e. quite standard PKI crypto): https://reference.opcfoundation.org/Core/docs/Part2/, that Part 2 also addresses security threats and so on. Here the SecurityMode has 3 options: None, Sign, Sign&Encrypt. Both signing and encryption depends on both sides trusting each others ApplicationInstanceCertificate.

The opc.https uses TLS for the encryption part. SecurityMode only controls signing (since the channel is already encrypted), has 2 options: None, Sign. Signing if enabled requires the same ApplicationInstanceCertificate both-side-trusting them as in opc.tcp. Note that HTTPS and ApplicationInstanceCertificate are different (most likely). Also do note, that with SecurityMode None, the situation is that no client-side TLS cert is required for connection (https://reference.opcfoundation.org/Core/docs/Part6/7.4.1/ “A Server shall allow Clients to connect without providing a Certificate during negotiation of the HTTPS connection.”). That might be dangerous (since it differs from opc.tcp semantics that for an encrypted channel connection requires both sides to trust eachothers). Thus I wouldn’t recommend to use the NONE option with opc.https (a different argument could be made that this use-case is the only usefulness of opc.https, but since it differs so much from typical opc.tcp I’m not sure how much sense it would be). Also it should be noted, that this is not “web-https” traffic, but the TLS channel is used for the same binary procotol as opc.tcp.