I am currently developing a product that involves two network situations. At the client side, multiple computers form a P2P network (multiple locations, multiple p2p networks), and a subset of nodes of each network establish a connection with a subset of servers we host (for data exchanges, updates). All servers and clients have certificates, signed with a CA certificate.
My problem now is the updating of (intermediate) CAs. I cannot ensure a simultaneous update of all machines at once (also for failsaves, a transition time would be appreciated), and so there has to be a period of time where multiple CA certificates are valid, a legacy version which will run out in non-negligible time, and an updated version to replace it.
Since the client waits with its authentication till it has recieved the server cert, it can react to an outdated CA and send it's own legacy certificate chain, and because the connection in the p2p networks will be attempted in both ways, I can ignore the case where a legacy client meets an updated server and just wait for it to happen the other way round.
But that does not work for the central servers, because the clients might hide behind a NAT Layer, also it would seem ugly to me to turn around the connection in a real client-server model. Just working with the legacy certificate until day x without offering a smooth transition seems risky to me.
So here finally the question, is it possible for an SSL server to offer a fallback certificate in case the current (intermediate) CA is unknown by the client.
I have two ideas for workarounds (on failure, remember the client's ip and send a different certificate on retry, or run the service on different ports with different certificates), but since updating CAs is an actual thing, i guess there should be be better solution.
Please enlighten me.