Q: What's the impact of renewing the enterprise root CA's certificate on our existing PKI clients and subordinate CAs?

A: Before discussing the impact of the renewal of your root Certification Authority's (CA's) certificate, you must understand how the validity period of the root CA certificate affects the validity period of the certificates it issues. A fundamental public key infrastructure (PKI) rule is that a CA can never issue a certificate that's valid beyond the expiration date of its proper certificate. This rule means that when a CA's certificate reaches the end of its validity period, all certificates it issued will have already reached their expiration dates. This rule directly applies to the subordinate CA certificates issued by your root CA, but also indirectly to the user or device certificates issued by your subordinate CAs. In other words, when the root CA's certificate expires, all certificates in the root CA's PKI hierarchy that were issued during the lifetime of the root CA certificate will have expired.

Renewing the CA certificate typically doesn't impact the PKI trust chain validation process that your PKI clients use for validating previously issued and newly issued certificates. All previously issued certificates automatically chain up to the old CA certificate and all newly issued certificates automatically chain up to the new CA certificate. This process is possible thanks to the Subject Key Identifier (SKI) in the CA certificate, and the Authority Key Identifier (AKI) and Authority Information Access (AIA) fields in each of the certificates a CA issues. For a short introduction to certificate chain validation, I refer you to "Certification path validation algorithm" on Wikipedia.

The SKI contains a unique Key Identifier (KeyID) for the CA's public key, which is basically a hash value that's calculated from the CA's public key. This KeyID is automatically added to the AKI field of each certificate that a CA issues. The AIA field holds an HTTP or LDAP URL that points to a download location where a PKI client can download a CA's certificate if it's not already present in the PKI client's local certificate store.

The only case where your PKI clients might experience certificate validation problems in the event of a root CA certificate renewal is when they can't access and download the root CA certificate from an online URL, or they don't already have a trusted copy of the CA certificate in the Trusted Root CA container of their local certificate store. This situation can also cause problems when you generate a new root CA certificate using a new key pair. In that case, the new CA certificate has a new KeyID value in its SKI value that's referred to in the AKI field of newly issued certificates. During certificate chain validation, the PKI logic uses this KeyID value to locate the new CA certificate, and if this certificate isn't available, certificate validation fails.

Windows includes an automated distribution mechanism for new CA certificates that's based on the Group Policy Object (GPO) application logic and Active Directory (AD), but certain PKI clients might not have received these certificate updates yet when they need to validate a certificate that was issued under the new CA certificate. Also, non-domain-joined PKI clients never get these certificates through GPOs (GPO settings aren't applied to non-domain-joined machines) and must rely on the accessibility of the AIA URLs to download the certificate during certificate chain validation. Still, these PKI clients will trust the old CA certificate that they downloaded before -- during previous certificate chain validations -- or that got pushed to them during a GPO application when they were connected to the domain.

To deal with this problem, Windows automatically generates two additional cross-certificates when you renew a root CA certificate using a new key pair: one cross-certificate that's signed by the old CA that certifies the new CA certificate, and one cross-certificate that's signed by the new CA that certifies the old CA certificate. You can find these cross-certificates in the /windows/system32/certsrv/certenroll file system folder.

Figure 1 shows an example of the renewal of the certificate of a CA named Contoso-DC-CA. For this CA, I first did a certificate renewal using the existing key pair, and then another renewal using a new key pair. You can see five certificates in the folder.

Figure 1: An example of certificate renewal (Click image for larger view)

The certificate without a number label behind it is the initial CA certificate (before renewal). The CA certificate with a (1) behind it is the certificate that was created after CA certificate renewal using the same key pair. The CA certificate with the (2) behind it is the certificate that was created after CA certificate renewal using a new key pair. The certificates with the (1-2) and (2-1) behind them are the two cross-certificates that were automatically generated when the root CA's certificate was renewed with a new key pair.

These cross-certificates can ensure that all certificates will be trusted, including those that chain up to the new CA certificate. When the new CA certificate isn't yet available on a PKI client, certificates issued under this new certificate will still be considered trustworthy because their certificate chain will point to the cross-certificate that ultimately chains up to the trusted old CA certificate. Similarly, newer or recently installed PKI clients might not trust the old CA certificate, but only the new CA certificate. Again, thanks to the (other) cross-certificate, these clients will trust a certificate that was issued under the old CA certificate, because it chains up to the new CA certificate.

These two cross-certificates are automatically published to the AD AIA container when you renew the CA certificate of an enterprise root CA using a new key pair. Also, the GPO logic automatically pushes these cross-certificates to the PKI client's Intermediate Certification Authorities certificate container. When you renew the CA certificate of a standalone root CA using a new key pair, you must publish the cross-certificates and also the new root CA certificate manually to AD. To do so, you can use the following certutil commands:

Certutil -dspublish -f  CrossCACertutil -dspublish -f  CrossCACertutil -dspublish -f  RootCA

In the above commands, you must replace  with the actual name of your new root CA certificate file, with the actual name of the first cross-certificate file, and with the actual name of the second cross-certificate file.

Remember that the only time these two cross-certificates will be used is when a PKI client validates a certificate and has only one of the two root CA certificates (old or new) in its Trusted Root CA certificate store. Independently of this workaround, you should always double-check that the old and new root CA certificates are pushed to all domain-joined PKI clients, are downloadable for non-domain-joined PKI clients, and finally, are present on all PKI clients in their Trusted Root CA certificate store. To make sure that your non-domain-joined PKI clients can download the certificates, you must make sure the old and new CA certificates are automatically uploaded to the AIA locations and that your clients can access the associated AIA URLs.