Hi,

Did you just ask out of interest, or did you have an actual case where some of these are happening?

https://reference.opcfoundation.org/Core/Part6/v104/docs/6.3
“All SecurityProtocols require that system clocks on communicating machines be reasonably synchronized…”
Thus, in general it is sort of a situation that should not happen.
In general SDK doesn’t expect the clock to magically jump and that can lead to basically any undefined behavior. Some of Java’s scheduledexecutors behave interestingly as well. For example, schedulewithfixedrate ignores the rate if it has not exec’d as many times as it should have if clock moves suddenly to the future. Things might timeout etc. However, in most cases the client would just reconnect to the server. IF the clock moves part the cert validity period it might stop the client. If the clock moves to the future enough that the server cert is not valid anymore the UaServer must be restarted with the new cert as far as I know.

For the certs, assuming you use one of the ApplicationIdentity.loadOrCreateCertificate, in practice if the hostname changes, then when that method is called it wouldn’t find the old file and thus would make a new cert with the new hostname (i.e. SDK doesn’t automatically check this periodically, if that is what you are asking). If the cert exist and is expired and enableRenew is true it would re-create it. I should note that in the future once we support GDS i.e. Global Discovery Server spec (https://reference.opcfoundation.org/GDS/v105/docs/) that would typically handle all certificates on a site. In practice certificate management is complicated and most have just used self-signed certificate that would last like 10 years or something. And the GDS will be a solution to that. Probably here we must also make something that allows swapping the cert while the app runs (or keep the old one for a roll-over period or something; though, I’m not exactly sure how clients will react to this kind of situations..).

If the hostname changes while the application runs, I’m not sure. At least the com.prosysopc.ua.ApplicationIdentity.getActualHostName() caches the value and returns the same value in subsequent calls, thus SDK wont notice it until the JVM restarts (or you can use ApplicationIdentity.setActualHostName(String), if you set null it would resolve it again). Note that I’m specifically meaning with hostname here the computername (e.g. what ‘hostname’ would result in when run in command line). Also the server would have the old hostname EndpointUrls, which some clients use when connecting (we do not, UaClient keeps using the original connection address given to it, because in reality the EndpointUrls might be from behind NATs etc.). Some clients do verify the connection address hostname part is found from the cert (similar to web browsers) and might fail, but the connection address maybe doesn’t change if the hostname changes, though typically the hostname is used as the connection address. So it depends.

In the stacktrace
at com.prosysopc.ua.ApplicationIdentity.loadOrCreateIssuerCertificate(SourceFile:864)
at com.aa.galileo.structure.protocol.opcua.OPCUAServer.initCertificates(OPCUAServer.java:490)

you call loadOrCreateIssuerCertificate, not loadOrCreateCertificate. Do you use the ‘enableRenew’ true also for the loadOrCreateIssuerCertificate call? (you showed loadOrCreateCertificate instead), because if it is false and it is expired you would get the very exception you saw.

If you just copied from the samples, it would seem the
KeyPair issuerCertificate = ApplicationIdentity.loadOrCreateIssuerCertificate(
“ProsysSampleCA@” + ApplicationIdentity.getActualHostNameWithoutDomain() + “_https_” + certKeySize, privatePath,
privateKeyPassword, 3650, false, certKeySize);
part does use ‘false’ for that. Though in the sample the whole CA cert is only created for the sake of the https cert, and the whole opc.https is also by default disabled in 5.x sampleconsoleserver (as really no-one should use opc.https).
Like you can make a CA cert this way and also use it for opc.tcp, though it is a bit odd if an application makes it, typically you have something more central that would manage the CA cert (unless you were test that). If an application itself makes a cert, typically that is just a self-signed cert (some SDKs didn’t work for opc.https unless there was a CA cert in use, thus that is why that exists there).

But if that is based on 4.x samples and you happen to have the opc.https stuff there, then it probably did break on that before it reached your loadOrCreateCertificate line.