I wanted to bring something to the community's attention as we have seen a couple cases recently for this issue, and it is an issue that will eventually impact any DX UIM environment that approaches 10 years of age.
When DX UIM hubs are connected via SSL tunnels, client certificates are issued from a tunnel server and distributed to the client hubs. These client certificates are "signed" by a built-in Certificate Authority which exists at the tunnel server. This Certificate Authority is in turn identified by a built-in Server Certificate that identifies the hub as the issuing authority for the client certificates. This certificate has a hardcoded expiration date of 10 years which cannot be extended.
Even as hubs are upgraded or migrated to new systems, if you have re-used the actual hub installation files, you may have been carrying a tunnel server certificate along for some time.
If this certificate expires, it can be somewhat painful to recover.
When the certificate that underlies the Certificate Authority expires, all client certificates will also be considered expired, even if the client certificate itself has an expiration date in the future.
Once the server certificate has been recreated, a new client certificate must be distributed to each client hub, and the client tunnel must be reconfigured from scratch. In a sense, it is like "starting over" with the tunnels - connectivity will be lost, and each hub will need to be touched outside the context of UIM in order to restore connectivity.
So I would like to recommend that all users who have implemented the hub-to-hub tunnels should take a moment to check the expiration date of this certificate, which can be seen in the hub GUI under 'Server Configuration' as indicated below:

Unfortunately, the only way to renew this is to disable tunneling and re-enable it again, to create a new 10-year certificate - but doing this will invalidate all the client connections, so even if you take this step prior to expiration, it will still have the same effect and require the same amount of work to recover.
In a small environment this may be fine but if you have a large number of tunnel clients it can be problematic.
In order to help address this problem, one possible solution is to set up a redundant tunnel connection for each client; you then would have a second route to use to communicate with the tunnel clients in order to facilitate the distribution of new certificates for the existing tunnel. You can also use UIM superpackages to distribute the new client certificate and associated configuration changes.
To that end, we have published a KB with a document that describes a detailed process for accomplishing this and I wanted to share it with the community.
KB Article Link
This article makes a couple of assumptions in terms of how the config sections in your hub.cfg will be numbered e.g. <1> <2> etc - this will depend on your existing setup and how many tunnels/clients/etc you have already configured, so some adjustments may be needed to fit your specific use case but I hope that this can help someone.
Special thanks to Garin Walsh, who gave me the idea to document this process.