We have a Java client application that talks to server side applications over the internet. The code is designed to use the TLSv1.2 SSLContext to establish a secure socket between client and server.
The problem we are facing is that we must update the client side keystores annually due to recent changes in industry standards. This requires clients to upgrade our software on a yearly basis because we can not obtain trusted certificates with an expiration longer than 1 year.
That is not such a big problem but, what is painful, is that all clients must be on the new keystore at the same time as the server side. So all the new certificates must be installed everywhere at the same time. Both client and server side.
This wasn't such a big deal to do every 3 years when we were able to obtain certificates with longer expiration dates. But it's too painful to do every year.
What I'm looking for is the ability to deploy new keystores to clients before the current certificates expire in controlled phases. Then, once all the clients are updated, install the new certificates and keys on the server side. This would be much less painful than the all-in-one-evening approach.
I tried installing the new certificate chains and keys in the current keystores so that the client application uses only one keystore containing both the older and new certificate chains and keys but I was not able to get this to work without exception. Some third party libraries that provide native support for secure sockets can not handle this.
The solution I came up with is to have the client application use two sets of keystores. One containing the current certificate chains and keys and the other the new ones. Then code the software to, on a certain future calendar date (the rollover date), switch over and use the new keystores. The rollover date must be earlier than the expiration date of the current keystores. This way we can deploy all the new keystores to our remote clients ahead of the rollover date and on the evening of the rollover date, update the server side with the new certs and keys. Of course then we have to make sure the new keystores become the current keystores before the next rollover date the following year.
This is crude and requires a lot of discipline on the part of developers and operations from having to be keenly aware of the rollover date and upgrade procedures. But I can not seem to come up with a more graceful way to handle this kind of migration in a controlled way.