The question is... a bit complex. The critical issues are existence and availability of intermediate CA certificates. Consider the following points:
Root CA are not "revoked". Revocation is a mechanism by which the issuer for a given certificate specifies, directly or indirectly, that one of its issued certificates is not to be trusted and must not be used for any purpose. Root CA have no issuer (they are "self-issued"); therefore, there is no entity qualified to revoke a root CA. As a result, no CRL or OCSP response will ever talk about a root CA certificate.
When a root CA is conceptually "renewed", the old CA just floats around. Trust in root CA is always direct: a client either trusts a root CA, or does not trust a root CA. As such, it is up to each client to decide whether to include the new root and/or to discard the old root. An important consequence is that there is no way to make a machine aware of a renewal. From the client's point of view, there is no such thing as a "renewal"; there are two distinct root certificates.
"Renewal" is not a well-defined concept. There are variations. Basically the new root CA may or may not use the same key, and may or may not use the same name. In fact, when the CA changes its name (its subjectDN), the notion that the new CA is a "renewal" of the previous one is a business concept; technically, this is just "another root CA".
There is no rule which mandates a change of key upon renewal. Decision to change the key should theoretically be driven by considerations on the safety of the private key storage, within the key lifecycle management. In short, you need to change the key when the previous one is too small with regards to current cryptanalytic results. If the root key is, say, RSA-2048, stored in a good HSM, then there should be no need to change the key. (This begs the question then: Why you would like to "renew" the CA in the first place? Usually, this is because the old root CA was tagged with an expiry date by someone who was not completely aware of what he was doing, and that date was not far enough in the future.)
When a client wants to validate the certificate of some SSL server, the client tries to build a valid certificate chain which goes from a root CA trusted by the client (the "trust anchor") down to the EE certificate (the "end-entity", i.e. the server's certificate). In between are the intermediate CA certificates. Rules for what constitutes a valid chain are mindbogglingly complex but, for the purposes of the discussion here, they can be summarized as follows:
- The signature on each certificate can be verified with the public key stored in the previous certificate.
- The
issuerDN of each certificate is equal to the subjectDN of the previous certificate.
- The current date is between the
notBefore and the notAfter dates of each certificate.
- Each certificate (except possibly the EE) contains a Basic Constraints extension with the
cA flag set to TRUE.
As long as the client can come up with such a chain, the client will be happy.
A consequence is that if you renew a root CA by reusing the same name and the same key (i.e. you just changed the validity dates), then the old and new root CA are interchangeable, as long as neither has expired. That is, every chain which begins with the old CA will be equally valid if you replace the old CA with the new CA. In that case, the transition is smooth: both your old "XP" user, and the new "Windows 8" client will be able to validate the same certificates, from both servers.
Now what if you changed the key and/or the name ?
Then trouble begins. For better illustration, let me switch to Microsoft terminology:
We are still at a time when both the old and new root are still valid (when the old root expires, it virtually disappears, so the "XP" user ceases to be able to validate anything).
The "old root" is called root0.
The "new root" is called root1.
As per Microsoft procedures, the renewal included a cross-certification. This kind of thing was initially meant for two distinct PKI to "merge" somehow, but it is also used for renewals. Namely, two extra intermediate CA certificates have been issued:
- root0-1 contains the name and key of root0, but is signed by root1
- root1-0 contains the name and key of root1, but is signed by root0
Note that whether a CA is "intermediate" or "root" is a property of the certificate, not of the actual CA. Here, both root CA have two certificates, one being "root" and the other "intermediate".
The first server's certificate (signed by the old root) is serverOld.
The second server's certificate (signed by the new root) is serverNew.
From the point of view of the "XP" user, both serverOld and serverNew can be validated, with the two following paths:
- root0 -> serverOld
- root0 -> root1-0 -> serverNew
while the "Windows 8" user can also validate the certificates with:
- root1 -> root0-1 -> serverOld
- root1 -> serverNew
So everything is fine ? Not so fast ! What I explain above is that the existence of the intermediate CA certificates root0-1 and root1-0 potentially allows for a smooth transition. But this works only if the said certificates are indeed made available in some way to the client.
An SSL client will build chains based on certificates found in three sources:
What the client already has. For instance, if you inspect the "certificate stores" in a Windows machine, you will see a store called "Intermediate Certification Authorities" which is a repository for intermediate CA certificates. These are not intrinsically trusted but are available for certificate path building.
What the server sent. As per the TLS specification, an SSL/TLS server does not send its certificate alone, but as part of a pre-built chain. A client is entitled to simply try that exact chain and nothing else; but, in practice, modern clients (Web browsers) will do some path building of their own if the chain from the server fails to validate. Importantly, the certificates from the pre-built chain sent by the server can be reused by the client to build other chains.
What the client can download by itself. Any certificate C may contain an Authority Information Access extension with URL pointing to places where "the" certificate of the CA which issued C can be obtained.
So if you want the "XP" client to use the "root0 -> root1-0 -> serverNew" chain, without being able to "push" the root1-0 certificate into the client machine through some out-of-band administrative operation, you have two options:
You may configure the server to send the "root1-0 -> serverNew" chain, instead of just "serverNew". That chain can be validated by the XP client, while the Windows 8 client should be able to notice that the "serverNew" certificate can be linked directly under the "root1" certificate.
Such server configuration cannot necessarily be enforced. First, SSL servers might be under control of people other than the PKI itself. Second, some SSL software cannot be (easily, or at all) configured to send a specific chain. For instance, IIS is configured with just the EE certificate, and will send what is from its point of view a valid chain; if the IIS machine trusts root1, it will not send a chain containing root1-0.
You could arrange for "serverNew" to contain an AIA extension which points at the root1-0 certificate. The XP client will use that URL to dynamically obtain the root1-0 certificate (and hopefully cache it locally for future usage). The Windows 8 client will be able to verify the "serverNew" certificate with root1 directly and will just ignore the extension.
The second solution must be applied on the new CA itself, so that when it issues certificates (e.g. serverNew), it includes an AIA extension pointing to root1-0. This is feasible; however, the dual case is not. The "dual case" is the validation of "serverOld" by the Windows 8 machine: with the cross-certificates, the Windows 8 machine must build "root1 -> root0-1 -> serverOld". However, "serverOld" was issued by the old root before the new root existed, and thus cannot contain an AIA pointing to root0-1, since that certificate did not exist at that time. A corrective action would be, when the new machine is configured with the new root, to also install the root0-1 certificate in its "intermediate CA" store.
Bottom-line: cross-certification does not work well. It is theoretically good, but it fails in practice because of the lack of availability of the cross-intermediate CA (these magic certificates exist, but there is no way to make all clients aware of their existence). In closed environments, cross-certification works: for instance, from an Active Directory server, you can forcibly push arbitrary intermediate CA certificates into all domain machines. You cannot do that in the Internet at large...
In practice, renewal strategies (for when key and/or name is changed(*)) overlap. The "new root" is simply handled as "another root". This is done in several phases:
- The new root is created. The new root CA certificate is installed in all machines. EE certificates are still issued with the old root.
- After a few months or years, the new root is put to use: EE certificates are now issued by the new root. This assumes that the new root has been distributed to all relevant clients during the first phase.
- When all EE certificates which were issued by the old root are expired, we just leave the old root alone, to die silently (ideally, the old root key is forcibly destroyed in a formal key ceremony).
But, really, root CA "renewals" are best avoided. In that respect, the Year 2038 will be a problem, because most root CAs have set their expiry dates in 2037 or earlier to avoid the potential issue (which is probably as exaggerated as the famous Y2K). Consequently, there will be a lot of renewals 20 years from now.
Intermediate CA renewals are easier, because clients download intermediate CA automatically by following AIA extensions (contrary to root CA). This can be explained in the following conceptual sense: validation is context-free. Clients don't trust or mistrust certificates based on history, but only on what certificate chains they can build right now. All certificates are supposed to be downloaded automatically or found in shared repositories or sent by parties to each other; that is, all certificates except the "trust anchors", which are managed manually. So clients have no notion of renewal. Intermediate CA certificates, and EE certificates, can be renewed transparently since they are meant to be downloaded anew every time (though they can be cached locally). But for root CA, local administrative action is required.
(*) It does not make much sense to keep the same key if you change the name. The opposite does make sense (same name, because that's the same formal CA entity, but distinct key) but, in practice, is best avoided: when Windows uses the wrong CA, instead of claiming "this path does not work because I don't have the right CA", it instead says "this path does not work because the certificate has been corrupted and you are under attack" (I am paraphrasing here, but the message is definitely and unduly scary).
