Log In
Register
Topic RSS
9:20, EET
September 1, 2025
Offline
Hi,
The generated certificates for a UaServer are configured to have a limited validity period. I have configured the code such that, sometime prior to the expiry of the generated certificate it is renewed automatically through a scheduler. This also sets the identity to the newly created ApplicationIdentity. The certificate is updated in the privatePath as expected, but when any new client attempts to connect to this UaServer, the client is provided with an expired certificate which was generated during the initial startup of the server.
Certificate and identity creation – ApplicationIdentity.loadOrCreateCertificate(appDescription, getOrganization(), getPassword(), privatePath, true, hostname);
Setting the identity – UaServer.setApplicationIdentity(identity);
Since there will be clients connected, I am trying to find a way to update the certificate/identity during runtime without a server restart. Is it possible to update the server certificate at runtime in a running UaServer instance? If yes, how? Does setApplicationIdentity() alone update what clients see, or do we need to reinitialize endpoints?
12:40, EET
April 3, 2012
Offline
Hi,
The SDK components are not yet designed for changing certificates. There are a lot more nuances to the matter though, but I’ll try to give a larger answer later.
In short, you must restart the UaServer. You might still run into issues regarding the clients, they might also need to be restarted.
15:57, EET
April 3, 2012
Offline
Actually, not sure could it even work by restarting the UaServer, you might need to .shutdown it and make a separate instance as some of the lower level components are initialized only once.
Anyway, now on the nuances and a longer version on the answer.
Based on the SDK method signature used, you create a self-signed certificate. The reality for those is that they are mostly made to practically never expire. Of course this is not ideal, but changing the certificate brings troubles since it needs to be trusted by all apps (again), so in practice most just make them last years. There might be scenarios where the certs are updated, but then just the applications are restarted as it doesn’t happen often (lets say, once per a year or two). There the renew flag does allow creating the new certificate, which is probably better than requiring using e.g. openssl to create one or loading an expired one.
OPC UA tries to fix this issue nowadays by introducing a concept called GlobalDiscoveryServer(GDS), that takes care of managing the certificates and trust lists of apps of a “factory floor”. There isn’t yet a lot support for it out there, things take time; we are also still building support it as well and it probably still takes .. some time, sorry. There are also some unanswered questions, thus more exploration is needed. Though, for self-signed certs, the same issues would happen with each renew, so I can open that a bit.
Since clients need to trust the new certs, ideally I think a server would have endpoints for both the old and new cert at the same time until all parties trust the new cert. If the server just swaps the cert, even if old connections would be kept active, they will eventually need to do a secure channel renew or there is a connection break. At that point depending on the client implementation it is broken until restarted.
Since the assumptions of certs being forever-lasting has been true for like more than 15 years at this point (or that apps just are restarted if the certs are updated), it is unclear can any client application out there deal with this on-the-fly. Also while in some rare cases a server has more than once cert, they have been for different security policies. Now there would be more than one for the same policy. Our own UaClient component for example cannot handle this scenario yet, it will select the first endpoint that is suitable, this happens only on the initial connection, it is never automatically checked again. It might be possible to make it work by nudging it to right direction by calling some methods and/or possibly ensuring certain orderings of endpoints returned by the server (this might be hard at the moment), but the point is that it is not automatic yet.
With GDS and/or CA-signed certs the above only happens if the CA cert itself needs to be renewed. With GDS managing app trust lists, it could resolve this by first updating the new CA to the lists well in advance before it starts to use it for signing. And the CA-signing resolves trust issues since new certs are signed by the CA which then gives already the trust (so dual endpoints would be needed only for certs made with different CA certs, for non-GDS-managed software). Though of course for this world to become reality all apps must then support GDS (or support dual endpoints and better cert selection). Some of this could be done today without GDS, though managing revocation lists is not possible, unless they are transmitted outside of OPC UA means to all apps.
There are some nuances on how a client selects even the endpoint. Of course it might make most sense to choose an already trusted cert that has the most time left until expiry. However, the validation process itself typically drives UI/dialogs to ask the user that is cert trusted if it is not yet. Thus on the other hand it would make sense to choose the latest cert so that it is becomes trusted. However if an UI is running unattended, it might break the app until attended, then it might have made sense to select the older, already trusted (but then there should be another mechanisms for asking trusts from the user; or just only rely on e.g. disk-based configuration).
Once we have GDS support in place, I think then we should support updating it on-the-fly (unless the exploration results that it would never work).
1 Guest(s)
