Hi,

Hard to say based on this info alone. There has been cases in the past where an OPC UA Server was implemented incorrectly, but was still connectable by UaExpert. Or could be our bug or a missing feature.

IF possible, please observe differences via https://prosysopc.com/blog/opc-ua-wireshark/ and let us know if any (use uajava-support@prosysopc.com if needed). IF you use Sign&Encrypt, note that then you cannot see traffic (contents) once the channel is encrypted, however here the failure happens before that. Thus check at least (the first) Hello message EndpointUrl field.
A typical OPC UA connection flow has the following messages:
(TCP socket opened)
Hello/Acknowledge
OpenSecureChannel (with NONE mode)
GetEndpoints
CloseSecureChannel
(TCP socket closed and a new one opened)
Hello/Acknowledge
OpenSecureChannel (with the chosen security mode)
CreateSession
ActivateSession
and so on

GetEndpoints gives EndpointDescriptions, which have the server certificate, which is needed for crypto operations. It is checked again once security is in place and server has proved itself to be real.

In this case the failure/difference is somewhere before GetEndpointsResponse i.e. in the (first) Hello, OpenSecureChannel (NONE) or GetEndpoints.

There has also been some recent cases that some server’s might not support NONE connection at all to the “main url” (i.e. you cannot even do GetEndpoints), but instead have a separate “/Discovery” endpoint for GetEndpoints. Our SDK design does ignore the EndpointUrl resulted from GetEndpoints and we keep connecting to the original addredss. This works with e.g. NATs where the server wouldn’t know it’s real address. But this fails when the main endpoint doesn’t support GetEndpoints. Thus, starting from 5.2.0 (thus please try with it) we support this case, but you must give the “opc.tcp://host:port/Discovery” (or equivalent) as the “real address” for UaClient. So basically 5.2.0 (https://downloads.prosysopc.com/opcua/Prosys_OPC_UA_SDK_for_Java_5_Release_Notes.html#version-5-2-0) does take (only) the ServerName component internally after GetEndpoints and uses the other parts as-is, thus it should work with a server like this. Rest of the address (i.e. the host:port part) comes still from the given address thus this should work with NATs. However, please note that based on the info it is not possible for me to know if this would be or not be the case here (but e.g. you/UaExpert could have obtained the so called EndpointDescription by the UaExpert menus depending how you configured the connection).

There is also a way to set the EndpointDescription manually, if you “magically know it” (this includes knowing the certificate of the server), by UaClient.setEndpoint, though note that set this way the url and security modes are taken as-is from it (so it might not work with NATs). If set, then the first connection (that would do GetEndpoints) is skipped and the second is started directly.