SSL (TLS v1.2) - Can i offer fallback CAs when upgrading Certificates? (Java)

Question

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.

Answer 1

The solution is: do nothing.

SSL servers and clients send their certificates as chains precisely because they cannot assume that the peer will already have all needed intermediate CA certificate. The whole point of certificate chains and intermediate CA is that a "relying party" (X.509 jargon meaning here "a client or a server") can validate a chain, any chain, as long as it already has the trust anchor, which is also known as "root certificate" or "root CA". I.e. the CA which is not an intermediate CA.

For instance, assume that there is in your system a root CA which everybody knows a priori (that's what root CA are for). Then there is the "old intermediate CA" called CA1, and the "new intermediate CA" called CA2. The server previously had a certificate S1 issued by CA1, but now has a newer certificate S2 issued by CA2. A client connects. What shall the server send ? Well, the server just sends the chain CA2->S2. The client might never have seen CA2 before; it does not matter. CA2 is issued (signed) by the root, and the client knows and trusts the root, so the client can verify the signature on CA2's certificate, and thus learn that CA2 is a valid intermediate CA that the client just had not hitherto encountered. Certificate validation then proceeds with the verification of the signature on S2, by CA2. Things just work.

X.509 certificates work in a hierarchical PKI model in which actors need to be aware of root CA, and of nothing more. These certificates have been designed for the exact purpose of avoiding the problem you are envisioning, i.e. distribution of intermediate CA. Any client (or server) can dynamically build any required trust chain based on whatever certificates it has at any moment, and since certificates are chained, how they are obtained is not important. In particular they can be received by the peer, and this transfer requires no additional trust.

So as long as all servers (and client) send their certificates as part of chains which are valid at that time, validation will work.

---

Now if you were talking about updating a root CA, then yes, that would become tricky. Trust is transported through the signatures on certificates; but it is not created out of thin air. It has to start somewhere, and that somewhere is an a priori, intrinsic knowledge of a trust anchor. To sum up, you really don't want to change your root CA often, because it is a mess. A root is supposed to be very long-lived. And this implies using intermediate CA, because a very long-lived root is a precious thing, so you really want to keep the root CA offline, and to use it as little as possible.