The SessionServiceHandler lacks the protected xxx(ServiceContext serviceContext, XXXRequest request, XXXResponse response) methods what are in the others. It goes more directly to the SessionManager. In the others they are sort of a "last effort place" to try to implement something, but regarding sessions SDK already should be implementing it .. completely (compared to e.g. data related to a Node's Attributes).

We do have intended ways for this as well: UaServer.getSessionManager().addListener(SessionManagerListener) see https://documentation.prosysop.....tener.html. Also, for just user-validation there is UaServer.setUserValidator(UserValidator).

We have also build ways to override the SessionManager via a subtype, similar to the handlers, though the raw ServiceRequest is not available (but the relevant parameters of it are, in the protected methods). It is also possible to use a subtyped Session.

Note that SDK already limits sessions and connections. They are separate things, though most of the time it is 1:1. By default SessionManager.getMaxSessionCount() defines max number of sessions and by default 10% more (at least +1) opc.tcp connections can be made. This so that a client can see that the server is at session limit. UaServer.setMaxOpcTcpConnections(Integer) can be used to set a different limit. Note that in the SDK (and per UA spec), non-properly-ActivateSession'd connections are dropped if at connection limit and a new one arrives. Note that there is not a way to observe the actual connections (we might build this some day).

> In practice we have not encountered that much “real world examples”
Yes, I guess our usecase is special: we are providing access to dynamically registered devices, kinda "OPCUA as a service" thing. But anyways, “Simple things should be simple, complex things should be possible.” is also valid here 🙂

One more question: You said you don't recommend overwriting SessionServiceHandler - for what reason? It would also be interesting for us to listen and monitor attempts to create (or activate) sessions, as those indicate the number of connections. And it would be good to use the same technique as with the other requests.

Thanks!

I did mean the EndpointServiceRequest version, but as long as you have not used UaServer.getLoopbackClient() (skipping details) then validateRequest(ServiceRequest, ServerSecureChannel) is ok as well.

In practice we have not encountered that much "real world examples". Like, the best one is our public Simulation Server instance which sometimes get "stuck" when someone makes many sessions so that the max sessions/connections limit is reached. But then again normally one has firewall rules that only accepts connections from defined sources, so not sure does even this count.

I will try the proposed approach and let you know, but it looks promising! I just guess you meant `com.prosysopc.ua.server.ServiceHandler.validateRequest(ServiceRequest, ServerSecureChannel)` ?

Regarding the rate limiting, yes, what you say makes sense, but how can an OPC UA server then deal with misconfigured clients and prevent being taken down by an unintended DoS? Do you have any recommendations or experience? I already asked about this in particular in this old thread, but a real-world solution was not found: https://forum.prosysopc.com/fo.....or-server/

There exists ServiceHandler.setRequestResponseListener(RequestResponseListener), which could be used for a logging-only scenario, you can get the XXXServiceHandlers from UaServer. This listener is called just before sending back the response (which should not be modified here). This is what our Simulation Server Application's Req/Res Log tab uses. Though, seems we have not used ServiceContext here in this Listener, thus the logic relies on com.prosysopc.ua.server.SessionManager.getSession(NodeId) using the authentication token from the header (though, this is what is also used for forming the ServiceContext).

Not exactly, as the point of an OPC UA SDK, in general, is to provide a higher-level abstraction and thus to try hiding the complex raw communication details.

10+ years ago the communication layers of OPC UA typically looked like:

+----------------------+
|         TCP            |
+----------------------+
|      UA Stack       |
+----------------------+
|       UA SDK        |
+----------------------+
|  UA Application  |
+----------------------+

Stacks were responsible to handling the raw socket connections, encoding messages to binary and then provide a raw request-response layer for the actual services. SDKs then abstract things more and provide something more use-able. What you basically say you would want would have been inside the Stack level, though 'SecurityToken' is not actually a "user token", but instead details related to the opc.tcp SecureChannel.

Nowadays Stacks are basically gone extinct. Some history regarding our SDK: https://documentation.prosysop.....ck-changes .We did make a mistake 15+ years ago that the stack classes were used directly in the SDK APIs, unfortunately fixing that might be impossible at this point. But basically other than those (and some util classes), classes being in 'com.prosysopc.ua.stack' package and subpackage should be considered to be "SDK private API".

That all is to say that it is not intended that you would normally handle the raw requests and doing so could break SDK's own functionality.

That being said, we do have some options, but it does require a bit more work. We would instead recommend using things that the sampleconsoleserver example shows, those are the intended ways, though that does involve attaching numerous XXXListeners to places for access control.

Anyway, you could try the following and let us know how it goes:
Subtype UaServer, override protected createXXXServiceHandler methods. Return sub-typed XXXServiceHandlers where 'XXX' is either 'Attribute', 'NodeManagement' or 'Subscription'. There exist also a SessionServiceHandler, but we recommend not to touch that one. Note that there are some methods that are final, those are historical Stack-to-SDK entry points and cannot be overridden.

However, you could override the com.prosysopc.ua.server.ServiceHandler.validateRequest(EndpointServiceRequest). It is recommended to call super first, to receive the ServiceContext that needs to be returned. You could throw ServiceException to fail the entire service. The ServiceRequest can be obtained from EndpointServiceRequest.getRequest(). However, I would be very cautious on doing any 'rate limiting' attempts, it is not something expected by UA Clients, they will either break or retry immediately, which would defeat the point.

The ServiceContext does tell the Session and from the Session you can get the ServerUserIdentity, which is server-side variation of the UserIdentity a client would use. The ServiceContext is a parameter in most of the recommended Listener-ways for handling authorization, it is passed along the call chain, see below.

An alternative is to look for methods such as https://documentation.prosysop.....dResponse- , and override them. These are called after the validate and then some of them will then split up more to other protected methods, then eventually they will go to YYYManagers. XXX and YYY might not be the same, but e.g. in Sessions it will go to SessionManager, which you can get normally from UaServer. It would provide info (a bit) about the sessions (UA has a Diagnostics concept). Many of YYY will have also YYYListener, here SessionManagerListener, that provides handles to react to their creation etc.

As this post is already quite long, I'll stop here for now, but please ask more and explain more about specifics what you would want to do.

I need finer control over client connections for various reasons (monitoring, statistics, access control, rate limiting, licensing, etc.).
I am interested in intercepting *all* low-level requests such as Create Session, Activate Session, Read, Write, Browse, etc.

Inspecting the code, the best would be to have a callback in the method `handleSecureMessage` of `OpcTcpServerConnection` (line 721), where I have access to the current `ServiceRequest` as well as `SecurityToken`. Unfortunately, the API doesn't provide access to this part of the code.

I also do not see any option in the `UaServer` API to inject any listener to handle requests on this level of granularity. Ideally, with the User token included.

Is there any option to intercept all requests, or would it be possible to build such an option in?

Thanks!

I've tested it and worked 😉

Also, for this reason I believe BouncyCastle will also ignore it, https://github.com/bcgit/bc-ja......java#L536 in the engineGetKey method.

So that explains why the privateKeyPassword does nothing and only the store password matters. However, based on my tests a JKS store can use both.

Then separate to this for the alias thing. SecureIdentity constructor has more documentation, https://documentation.prosysop.....ng.String- the com.prosysopc.ua.ApplicationIdentity.ApplicationIdentity(File, String, String, String, String) does call this super constructor. There is a mention "alias - string alias of the key pair, if null or not found in specified pfx-file, last entry is used". This something very old, but I would believe the intention is that .NET world used pfx files, but not in a way that there would be more than a single key so rather than fail it will fall back to the only key there is anyway. Since you probably as well have only a single key there, it is always found regardless of the alias.

P.S.
One extra note for future readers. This was a DEBUG level log. On failure it should use Charset.defaultCharset() as a fallback. With that there would only be issues if there are non-ASCII characters in the outputs.

Unfortunately formats other than the .der/.pem the samples use are not that well tested (or tested continuously/automatically).

Seems to be a bug. During https://downloads.prosysopc.co.....sion-5-4-0 + https://documentation.prosysop.....eir-usages we did do some changes. As a result BouncyCastle is not installed, only the Provider is loaded and used directly via java.security.XXX.getInstance(String, Provider). Few places are different, since e.g. BouncyCastle doesn't support the JKS type, but seems that was missed for the SecureIdentity case.

As to why it loads with wrong-things, not sure. My guess would be that since https://downloads.prosysopc.co.....sion-5-6-2 did fix a thing where BouncyCastle seems to return null for some erroneous data instead of throwing (I believe this was at least empty byte[]), maybe something similar can happen here. Then the scenario could become the same as if no cert was defined, which would be ok for NONE security connections.

Can you send mail to jsdk-support@prosysopc.com and refer this; we can give a beta build once we have fixes (might not happen today).

C:\Users\home>chcp
Aktive Codepage: 850.

There is a dot at the end. Seems to be different with different system languages.

On the machine that caused the log, could it be possible to see the output of the command "chcp" (without quotes) from the Command Prompt (specifically cmd, not powershell). It should output like this:

i.e. no dot at the end, but the number can be different on locales and regions. At least that it how it worked on the windows 10 and 11 machines we tested on.

A workaround would be to set the hostname manually (if you know it) via static ApplicationIdentity.setActualHostName(String), then SDK doesn't try to figure out it by itself.

We can also try to improve the parsing logic once we see the output. It should be noted that normally at least currently the only scenario where SDK will try to use platform specific ways is if there is or has been Docker installed on the machine at some point. The Docker's installation will write some hosts file entries that break Java's reverse-DNS lookup for the hostname that we use. This would result in an unusable "host.docker.internal" hostname, thus as a fallback we will attempt platform specific ways. On windows the console output encodings can be different and it matters for reading because there can be special characters, thus we try to parse it from the chcp output.

My pfx showed anyway 'PrivateKey (Format): PKCS#8' but it looks like it could be loaded with SDK 4.x also with "JKS" as keyStoreType

I'm using following constructor: to load a pfx file.

public ApplicationIdentity(File storeLocation,
String alias,
String privateKeyPassword,
String keyStorePassword,
String keyStoreType)

Create an identity with an application certificate. The certificate and private key are loaded from a pfx-keystore file.

keyStoreType - type of the key store, "JKS" and "PKCS12" are supported types

With SDK 4.x I used following code:

ApplicationIdentity applicationIdentity = new ApplicationIdentity(new File(keystore), alias, password, storePassword, "JKS");

With this the pfx file could be loaded and a connection to a server was possible.

With SDK 5.x the loading failed with:

2026-05-07 17:52:15,886|DEBUG|CryptoUtil |CryptoUtil init, trying to get: Windows-PRNG
2026-05-07 17:52:15,915|DEBUG|CryptoUtil |CryptoUtil init, using Windows-PRNG, random=PRNG
2026-05-07 17:52:15,915|DEBUG|CryptoUtil |Providers=[SUN version 17, SunRsaSign version 17, SunEC version 17, SunJSSE version 17, SunJCE version 17, SunJGSS version 17, SunSASL version 17, XMLDSig version 17, SunPCSC version 17, JdkLDAP version 17, JdkSASL version 17, SunMSCAPI version 17, SunPKCS11 version 17]
2026-05-07 17:52:16,563|INFO |CryptoUtil |Using CryptoProvider com.prosysopc.ua.stack.transport.security.BcCryptoProvider
2026-05-07 17:52:16,575|ERROR|CreateApplicationIdentity |Failed to load ApplicationIdentity from KeyStore ./resources/opcua-keystore.pfx with Alias myAlias
2026-05-07 17:52:16,578|ERROR|DefaultErrorHandler |com.prosysopc.ua.SecureIdentityException: Cannot load key from PKCS12 KeyStore: JKS not found
com.prosysopc.ua.SecureIdentityException: Cannot load key from PKCS12 KeyStore: JKS not found
at com.prosysopc.ua.SecureIdentity.(SourceFile:?)
at com.prosysopc.ua.ApplicationIdentity.(SourceFile:?)

When I change the keyStoreType from JKS to PKCS12 ....

ApplicationIdentity applicationIdentity = new ApplicationIdentity(new File(keystore), alias, password, storePassword, "PKCS12");

...then it loads, but I observed it is always loading as long as the storePassword is correct.

If I use a wrong-alias or a wrong-password it is still loading and I can get a connection to an OpcUa server.

ApplicationIdentity applicationIdentity = new ApplicationIdentity(new File(keystore), wrong-alias, wrong-password, storePassword, "PKCS12");

With 4.x and JKS a connection was not possible when alias ot key password was wrong.

Was there any change in the internal implementation? I could'nt find any hint in the Migration Guide or in the ReleaseNotes.