Please consider registering

sp_LogInOut Log In sp_Registration Register

Register | Lost password?
Advanced Search

— Forum Scope —

— Match —

— Forum Options —

Minimum search word length is 3 characters - maximum search word length is 84 characters

sp_Feed Topic RSS sp_TopicIcon
opc.https sessions wrong information (method: server.getSessionManager().getSessions())
May 10, 2023
17:58, EEST
Francesco Zambon
Forum Posts: 62
Member Since:
December 20, 2021
sp_UserOfflineSmall Offline


Please can you check the following use case:

1 Connect an OPC UA client to the server via opc.https
2 Connect a second OPC UA client to the server via opc.https
3 Print the data of the sessions with the method


The RemoteAddress attribute is wrong. Method:


The remoteAddress of the second client’s session overwrote the remoteAddress of the first client’s session.

Best regard,

May 10, 2023
18:58, EEST
Bjarne Boström
Forum Posts: 941
Member Since:
April 3, 2012
sp_UserOfflineSmall Offline


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.
.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.

May 12, 2023
12:41, EEST
Francesco Zambon
Forum Posts: 62
Member Since:
December 20, 2021
sp_UserOfflineSmall Offline

Dear Bjarne,

Thank you for the explanation.
Currently I don’t need the opc.https protocol.
I’ll study the specs later.

Best regards,

Forum Timezone: Europe/Helsinki

Most Users Ever Online: 518

Currently Online:
10 Guest(s)

Currently Browsing this Page:
1 Guest(s)

Top Posters:

hbrackel: 130

pramanj: 86

ibrahim: 75

rocket science: 72

Francesco Zambon: 62

Sabari: 62

kapsl: 57

gjevremovic: 49

Xavier: 43

fred: 41

Member Stats:

Guest Posters: 0

Members: 651

Moderators: 16

Admins: 1

Forum Stats:

Groups: 3

Forums: 15

Topics: 1415

Posts: 6035

Newest Members:

u310498, ntd, francescac, yahya95, leomajoe, Gus, sdfsdfsdfsd, riatuccker

Moderators: Jouni Aro: 988, Otso Palonen: 32, Tuomas Hiltunen: 5, Pyry: 1, Petri: 0, Bjarne Boström: 941, Heikki Tahvanainen: 402, Jukka Asikainen: 1, moldzh08: 0, Jimmy Ni: 25, Teppo Uimonen: 21, Markus Johansson: 42, Niklas Nurminen: 0, Matti Siponen: 288, Lusetti: 0, Ari-Pekka Soikkeli: 5

Administrators: admin: 1