Hi,

I guess. Technically it is sort of an issue with OPC UA in general, but this is technically caused by our UA SDK for Java and currently the application running at the demo is the Simulation Server application.

However that being said, it should now work. Note that the certificate was recreated as part of a workaround (generally the connections in this case are with NONE security mode, but as we always send it to be backwards compatible with UA 1.01 so clients might do validation for it still).

Additionally while it is sort of fixed, a client application generally should still be able to deal with the problem. Technically speaking, the specification mentions in 1.04 Part 12 Discovery Annex A “Firewalls and Discovery”:
“
Note that Servers may not be aware of all HostNames which can be used to access the
Server (i.e. a NAT firewall) so Clients need to handle the case where the URL used to access
the Server is differen t from the HostNames in the Certificate. This is discussed in more detail
in Part 4.
“

And additionally in Part 4 section 5.5.2.1 at the end for the Description of OpenSecureChannel service:
“
Clients should be prepared to replace the HostName returned in the EndpointDescription with the
HostName or the IP addresses they used to call GetEndpoints.
“

For these reason sometimes the endpointUrl might needed to be ignored or do the replacing and just continue trying to open a session by via the original connection url, but passing one of the discovered EndpointUrls within the CreateSessionRequest. For this reason this hasn’t been that big of a problem.

P.S. The server might be offline for a second time (+ a second cert change) later today as we’ll do some version upgrades. The address space might slightly change as well.