Hi,

The opc.https is different than opc.tcp, in more than one way. Writing a full answer would take multiple hours, thus skipping most.

In short just stop using opc.https, unless you have a real need. Basically there is almost no real-world use-cases that couldn’t be done via opc.tcp. As noted by Matti in the earlier thread, https://forum.prosysopc.com/forum/opc-ua-java-sdk/sampleconsoleserver-opc-https-endpoint-prosys-opc-ua-sdk-for-java-4-9-0-43/,
“. It is recommended to use OPC UA TCP instead whenever possible.”.
Better way is to say, use opc.tcp always. If you literally cannot (and cannot change that in any way), but could opc.https, then you can use opc.https.

And we really should disable opc.https in the samples in the future or in the next major version. That is at least my personal opinion. Since no-one supports that or do so poorly, it just causes confusion, as shown here. And while we would expect users to read the sample code, it can be security-wise a pitfall if you enable opc.https without knowing what it does. Copied below from SampleConsoleServer:
” /*
*
* NOTE! The MessageSecurityMode.None for HTTPS means Application level authentication is not
* used. If used in combination with the UserTokenPolicy ANONYMOUS anyone can access the server
* (but the traffic is encrypted). HTTPS mode is always encrypted, therefore the given
* MessageSecurityMode only affects if the UA certificates are exchanged when forming the
* Session.
*/
server.getHttpsSecurityModes().addAll(SecurityMode
.combinations(EnumSet.of(MessageSecurityMode.None, MessageSecurityMode.Sign), supportedSecurityPolicies));
“
(in opc.tcp if you use security the application-lvl auth is always done)

Anyway, as to why it works like that: https://reference.opcfoundation.org/Core/Part6/v105/docs/7.4
“
All HTTPS communications via a URL shall be treated as a single SecureChannel that is shared by multiple Clients.
…
HTTPS connections have an unpredictable lifetime.
“

So basically you cannot use it like that. I’m not sure is there a way to do that easily. Since basically no-one does support opc.https and we basically just run very simple tests on it and do not use it ourselves for anything real, it has not been a priority.