Avatar

Please consider registering
guest

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
ApplicationUri definition and certificate handling
April 18, 2023
14:46, EEST
Avatar
Hendrik Ulbrich
Member
Members
Forum Posts: 14
Member Since:
June 27, 2018
sp_UserOfflineSmall Offline

Hello together!

I have a question regarding the ApplicationUri. I found the following definition:
ApplicationUri is a unique identifier for each running instance.
How exactly is “each running instance” to be understood.

We have the following configuration with a specific HPE NonStop Server system:
1 test system, let’s call it “tsystem” for example.
1 production system, let’s call it “psystem” for example.

Both of them are running several Prosys-OPC UA Server server processes (Java VM’s) under different ports. The whole thing has to do with some kind of static load balancing.

Should you really configure a separate ApplicationUri for each server process (own port!) e.g. “urn:tsystem.com:OPCUA:serverProcessA” on port 4861 and “urn:tsystem.com:OPCUA:serverProcessB” on port 4862?

Or is one ApplicationUri sufficient for both/all processes? e.g. “urn:tsystem.com:OPCUA:server”.

Background is the usage and handling of the certificates we want to have signed by our CA. The question now is how many certificates do we need. We have up to 16 processes on the production system.

April 18, 2023
16:17, EEST
Avatar
Bjarne Boström
Moderator
Moderators
Forum Posts: 986
Member Since:
April 3, 2012
sp_UserOfflineSmall Offline

Hi,

I guess a better definition is https://reference.opcfoundation.org/Onboarding/v105/docs/3.1.2:
“3.1.2 ApplicationUri
a globally unique identifier for an OPC UA Application running on a particular Device. “
So basically it must be a “network-wide” unique identifier, i.e. for each connection address within a network an UA Client could take there must be an unique ApplicationURI behind it.

Applications such as the https://www.prosysopc.com/products/opc-ua-gateway/, https://www.prosysopc.com/products/opc-ua-historian/ and https://www.prosysopc.com/products/opc-ua-forge/ that can aggregate multiple OPC UA servers do use the ApplicationURI (as it must be unique) as a prefix for the NamespaceUris (as these are server-unique).

So, in short it depends that can the clients here chose which server/port they wish to connect to (or maybe even connect to more than one at a time), OR is there some external load balancer that chooses to which server the client is routed to and the fact that there are multiple servers is completely transparent to the client.

The OPC UA Specification has some parts regarding redundancy, please read https://reference.opcfoundation.org/Core/Part4/v104/docs/6.6.2 (though note that the SDK doesn’t support all of them and basically the ones supported need manual work for failover handling):
If Transparent:

6.6.2.3 Transparent Redundancy
6.6.2.3.1.1 Client Behaviour

To a Client the transparent Redundant Server Set appears as if it is just a single Server and the Client has no Failover actions to perform. All Servers in the Redundant Server Set have an identical ServerUri and an identical EndpointUrl.”

And it might not be that clear from the text, but (https://reference.opcfoundation.org/Core/Part4/v105/docs/3.1.13) the “ServerUri” in this context means the ApplicationURI.

IF Non-Transparent: then https://reference.opcfoundation.org/Core/Part5/v104/docs/6.3.9, and the server should have:
“ServerUriArray is an array with the URI of all redundant Servers of the OPC UA Server. See OPC 10000-4 for the definition of redundancy in this standard. In a non-transparent redundancy environment, the Client is responsible to subscribe to the redundant Servers. Therefore the Client might open a session to one or more redundant Servers of this array. The ServerUriArray shall contain the local Server.”
Basically the clients would use the ApplicationURI here as a key, so it must be unique.

P.S.
For the Transparent Redundancy the EndpointUrl requirement might not make sense sort of, but basically this is something the load balancer should magically fix maybe.
I should also note that this topic is complex and basically redundancy hasn’t been that much used yet.

P.S.2
This is somewhat in a way related, so mentioning https://forum.prosysopc.com/forum/opc-ua-java-sdk/connection-via-vpn-tunnel/ (and the next release will contain a fix that will allow mapping to different port, might be relevant for this thread as well).

April 19, 2023
8:18, EEST
Avatar
Hendrik Ulbrich
Member
Members
Forum Posts: 14
Member Since:
June 27, 2018
sp_UserOfflineSmall Offline

Bjarne Boström said
So, in short it depends that can the clients here chose which server/port they wish to connect to (or maybe even connect to more than one at a time), OR is there some external load balancer that chooses to which server the client is routed to and the fact that there are multiple servers is completely transparent to the client.

I’ll try to describe it a little better:

It is exactly one physical hardware with the address “tsystem.com”. The system is somewhat limited in multithreading in Java, so we run an OPC UA Server process with its own port on each CPU.

opc.tcp://tsystem.com:4861/OPCUA/ServerProcess1
opc.tcp://tsystem.com:4862/OPCUA/ServerProcess2
opc.tcp://tsystem.com:4863/OPCUA/ServerProcess3
opc.tcp://tsystem.com:4864/OPCUA/ServerProcess4

In each process different OPC methods are published, different credentials are configured and thus different applications are handled.

An OPC client or PLC gets exactly one of the 4 addresses. And also only there access and also only there the application runs.

In interaction with the certificates it gets a bit complicated now. From our point of view there are 2 possibilities:

A)
Addresses:
opc.tcp://tsystem.com:4861/OPCUA/ServerProcess1
opc.tcp://tsystem.com:4862/OPCUA/ServerProcess2
opc.tcp://tsystem.com:4863/OPCUA/ServerProcess3
opc.tcp://tsystem.com:4864/OPCUA/ServerProcess4

ApplicationUris:
urn:tsystem.com:OPCUA:ServerProcess1
urn:tsystem.com:OPCUA:ServerProcess2
urn:tsystem.com:OPCUA:ServerProcess3
urn:tsystem.com:OPCUA:ServerProcess4

In this case we need 4 different certificates or one certificate with all addresses, which would have to be extended for new processes.

B)
Addresses:
opc.tcp://tsystem.com:4861/OPCUA/Server
opc.tcp://tsystem.com:4862/OPCUA/Server
opc.tcp://tsystem.com:4863/OPCUA/Server
opc.tcp://tsystem.com:4864/OPCUA/Server

ApplicationUris (all the same):
urn:tsystem.com:OPCUA:Server
urn:tsystem.com:OPCUA:Server
urn:tsystem.com:OPCUA:Server
urn:tsystem.com:OPCUA:Server

In this case we need only 1 certificate or only one entry in the certificate, which would make everything a bit easier regarding our processes.

PS:
To the outside it could be seen as 1 server reachable on different ports. But the ports can’t be freely chosen by the client to maintain our load balancing.

April 19, 2023
14:47, EEST
Avatar
Bjarne Boström
Moderator
Moderators
Forum Posts: 986
Member Since:
April 3, 2012
sp_UserOfflineSmall Offline

Sorry, I made one mistake in the post. So, a server can have multiple endpoints, so it would be possible to “arrive” to the same server via multiple addresses, though like typically this is just e.g. using the IP address instead of the hostname and so on. Binding a second port for the same server wouldn’t exactly make sense (I have not seen this done), but e.g. from outside a NAT the port could be different.

Also, a clarification: The ApplicationURI doesn’t directly have anything to do with a connection address. In our SDK samples and our applications they sort of have related data, because it does also produce an unique ApplicationURI, but it can be any valid URI e.g. ‘urn:uuid:some_uuid_here’ and so on, as long as it is unique to the network.

From your explanation I interpret that these are basically 4 compelety separate OPC UA Servers that just happen to be hosted on the same machine? I know little of the HPE NonStop, but I am a bit a aware that it was a bit special platform, but I’m not sure does it matter here at least OPC UA Specification-wise. I’m not … 100% sure could you “stretch the spec” to intrepret these being separate endpoints each having own set of users allowed to use those endpoints and having complete custom data for the “same server”. I would not recommend trying (at least with the info I have), instead each server should have unique ApplicationURI.

I do realize that it might be sort of a pain to manage the certs in this case, but since it is theoretically possible for an application to connect to all these servers (e.g. you could have https://www.prosysopc.com/products/opc-ua-monitor/ showing each status etc.), and they are different servers, they should all have unique ApplicationURIs. If you would effectively segment the network so that it is technically impossible to connect to them from a single network, then maybe the same ApplicationURI could be used. But you might then someday wish to tunnel all these to a single aggregated point e.g. via UaGateway, and thus you would have the issue again, and it might be a pain to then change to use unique ApplicationURIs (or maybe even impossible). Plus interaction with a LDS (LocalDiscoveryServer) and/or GDS (GlobalDiscoveryServer) might be problematic. By default each Server should try to register to the LDS when they start, so they would overwrite each-others for example. Basically “many things” do key on the ApplicationURI.

It is possible that you would never use or run into the above scenario (and maybe you do not run a LDS). Or maybe I made a mistake in the assumption that it would be possible to connect to all of them (it sort of “doesn’t matter”, spec-wise, if you artificially limit this via credentials, the GetEndpoints is used without security/credentials and any client in the network could do that for example).

This is a bit complicate topic, thus the answer is the same.., what do you think about this?

P.S.
Could you explain a bit more on the multithreading limitations of the platform? Because basically this all would be so much easier if you can just run a single server and limit what each user can see. Or maybe I did misunderstand something, but what I did find quickly on the internet (https://www.hpe.com/psnow/doc/4aa6-6097enw.pdf) it should basically just support java thus I would find it odd if there would be any major issues (but maybe this is not the device you have but e.g. some older etc.).

April 24, 2023
8:55, EEST
Avatar
Hendrik Ulbrich
Member
Members
Forum Posts: 14
Member Since:
June 27, 2018
sp_UserOfflineSmall Offline

First of all, thank you for the detailed answer.

Regarding the HPE Non Stop platform, just briefly: Java8 and Java11 are implemented, but with restrictions regarding the server architecture and CPU core usage of Java VMs.

From the rest of the answer I can see that it is definitely better and more in line with the OPC standard to assign a unique application URI for each of the 4 OPC servers (processes) mentioned in the example.

Is it possible or allowed to work with wildcards in the subject alternative names (SAN) in a certificate? I know this only for subdomains.
But I have something like this in mind:
urn:tsystem.com:OPCUA:ServerProcess*

So you could run this configuration with only one certificate:

A)
Addresses:
opc.tcp://tsystem.com:4861/OPCUA/ServerProcess1
opc.tcp://tsystem.com:4862/OPCUA/ServerProcess2
opc.tcp://tsystem.com:4863/OPCUA/ServerProcess3
opc.tcp://tsystem.com:4864/OPCUA/ServerProcess4

ApplicationUris:
urn:tsystem.com:OPCUA:ServerProcess1
urn:tsystem.com:OPCUA:ServerProcess2
urn:tsystem.com:OPCUA:ServerProcess3
urn:tsystem.com:OPCUA:ServerProcess4

Otherwise, we would discuss internally whether we work with sub-certificates in a chain.

April 24, 2023
11:52, EEST
Avatar
Bjarne Boström
Moderator
Moderators
Forum Posts: 986
Member Since:
April 3, 2012
sp_UserOfflineSmall Offline

The https://reference.opcfoundation.org/Core/Part6/v105/docs/6.2.2 for subjectAltName says “…Shall include a uniformResourceIdentifier which is equal to the applicationUri. …”. Which I would assume to mean “no”.

But this case is interesting and maybe somewhat unique, so maybe you should ask the OPC Foundation directly: https://opcfoundation.org/forum/ (maybe link this thread).

Assuming my assumption holds (at least it does for our SDK and apps), basically every existing OPC UA Client would just check here here: ‘urn:tsystem.com:OPCUA:ServerProcess*’ not equals ‘urn:tsystem.com:OPCUA:ServerProcessX’ and report an error (or require some override).

Forum Timezone: Europe/Helsinki

Most Users Ever Online: 518

Currently Online:
26 Guest(s)

Currently Browsing this Page:
1 Guest(s)

Top Posters:

Heikki Tahvanainen: 402

hbrackel: 138

pramanj: 86

rocket science: 81

Francesco Zambon: 81

Ibrahim: 76

Sabari: 62

kapsl: 57

gjevremovic: 49

Xavier: 43

Member Stats:

Guest Posters: 0

Members: 713

Moderators: 7

Admins: 1

Forum Stats:

Groups: 3

Forums: 15

Topics: 1476

Posts: 6294

Newest Members:

mariam6210, donblanchard632, HowardLon, delilahhuggard, salvadorcolby69, HelenImpar, MnoioDat, babuinsobaka, Miikka Mikkonen, rickeylipinski

Moderators: Jouni Aro: 1015, Pyry: 1, Petri: 0, Bjarne Boström: 986, Jimmy Ni: 26, Matti Siponen: 328, Lusetti: 0

Administrators: admin: 1