Renewing a certification authority
Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2
Renewing certification authorities
Why certification authorities need to be renewed
A certification authority may need to be renewed for either of the following reasons:
Change in the policy of certificates issued by the CA
Expiration of the CA's issuing certificate
Certification authority validity periods
Every certificate issued by a certification authority (CA) has a validity period. The validity period is the range of time where the certificate can be accepted as an authoritative credential of the identity of the subject of the certificate. This is, of course, assuming the certificate is not revoked before the validity period ends and that the issuing CA is trusted. The primary purpose of the validity period is to limit the time in which a certificate is exposed to the possibility of being compromised.
Since a CA is really just another entity that has been issued a certificate--either issued by itself (in the case of a root CA) or issued by a parent (in the case of a subordinate CA)--every CA has a built-in expiration date, as determined by the end of the validity period on its CA certificate. This is not meant to imply that the lifetime of a CA is equivalent to the validity period of its CA certificate, only that a CA cannot issue certificates if it does not have a valid certificate of its own. The lifetime of a CA includes the validity periods of all its CA certificates--past and present. With these considerations in mind, an organization with a public key infrastructure (PKI) has to plan for the renewal of every certificate that is issued to a CA in the certification hierarchy in order to maintain the existing trust relationships in the PKI and to extend the lifetimes of CAs.
The validity period of a CA and the validity period of the certificates it issues
Before discussing the renewal of a CA certificate, it is helpful to understand how the end of the validity period of a CA affects the validity period of the certificates it issues. Certificate Services enforces a rule that a CA never issues a certificate to be valid beyond the expiration date of its own certificate. Therefore, when a CA's certificate reaches the end of its validity period, all certificates it has issued will also expire. This way, if the CA is purposely not renewed and the CA reaches the end of its lifetime, a PKI administrator can be assured that all the certificates that the now-expired CA has issued can no longer be used as valid security credentials. In other words, there will be no "orphaned" certificates that are still within their validity period but which have been issued by a CA that is no longer valid.
To illustrate how a decreasing validity period works, consider the following scenario: An organization installs a root CA with a certificate validity period of five years. The organization then uses this root CA to issue certificates with a validity period of two years to subordinate CAs. For the first three years every certificate issued to a subordinate CA by the root CA will continue to have a validity period of two years. After three years, when there is less than two years left in the validity period of the root CA certificate, Certificate Services begins to reduce the validity period of the certificates issued by the root CA so that they do not exceed the end of the CA's certificate's expiration date. Therefore, after four years, the CA issues subordinate CA certificates that are valid for one year. After 4.5 years, issued subordinate CA certificates have a validity period of only six months.
Certificate Services allows for the following maximum validity periods that are based on the type of certificate. These validity periods are configurable by the Domain Admin or Enterprise Admin when using version 2 certificate templates:
| Type of certificate | Maximum validity period |
|---|---|
Root CA |
Specified during setup of Certificate Services |
Subordinate CA, Internet Protocol Security, Enrollment Agent, Domain Controller |
Up to 5 years, never more than the Root CA's validity period |
All other certificates |
1 year, never more than the Issuing CA's validity period |
Planning for the renewal of a CA
Since a CA that is approaching the end of its own validity period issues certificates valid for shorter and shorter periods of time, you need to have a plan in place to renew the CA well before it expires in order to avoid issuing certificates of a very short validity period.
One renewal consideration: When you renew a CA, you have the option of reusing its existing key pair or generating a new key pair. When you generate a new key pair for a CA that is being renewed, a new certificate revocation list (CRL) distribution point is also created. This is to ensure that the key used to sign a certificate issued by the CA also matches the key used to sign the CRL. For more information about how renewing a CA with a new key affects certificate revocation and the name of CRLs, see Revoking certificates and publishing CRLs.
The following strategies are presented as possible approaches an organization could take when planning for CA renewal. You may need to adapt these to your specific situation.
Renewing a root certification authority
Since the root CA is the most critical CA in the hierarchy, you may prefer to have a strategy here that reduces the need to renew the root certificate often.
The first consideration is choosing the key length of the root's public key and private key pair during setup of the root authority. By using a long key length, which is generally more secure against brute force attack than a shorter key length, you increase the length of time that the CA can use the same private key and have reasonable confidence that it has not been compromised. The second consideration is establishing the validity period of the root certificate itself. In general, you will want to create a root certificate that has a shorter validity period than the estimated lifetime of the key.
Keeping these considerations in mind, a possible strategy for setting up a root CA that reduces the need for frequent renewal would be to create a 4096-bit RSA key during Certificate Services setup. Given the current state of computer technology, one estimate is that a 4096-bit private key is reasonably secure from a brute force attack for 15-20 years. After creating the 4096-bit key in Certificate Services setup, you could create a root certificate using the 4096-bit key that is valid for five years. Afterwards, the CA's certificate should be renewed every four years (one year before the expiration of the validity period), each time with a certificate validity of five years. Of course, every time the CA certificate is renewed, the administrator will have to assess whether the same key, given current computer technology and other security considerations, can be used with confidence for the next five years.
Renewing a subordinate certification authority
Intermediate CAs
Within an organization's certification hierarchy, some subordinate CAs may be "intermediate" CAs . In other words, they do not issue certificates to end users or computers; they only issue certificates to other subordinate CAs that are below them in the certification hierarchy. For these intermediate CAs, given their limited role and the relative ease of monitoring their certificate database logs, a possible strategy may be to renew them a year to six months before they expire and reuse the existing key.
Issuing CAs
For a subordinate CA that issues certificates to end users and computers, referred as an issuing CA, a preferable strategy may be to renew the CA's certificate regularly with a new key 6-12 months before the end of the CA's validity period, for example. This makes an attack on any one key less valuable, since any compromised key would have a relatively limited lifetime.
The other advantage of renewing an issuing CA using a new key is CRL management. When a CA is renewed with a new key, it begins to publish a separate CRL for the revoked certificates it has issued using the new key. It also will continue to publish a CRL for certificates signed with the old key, for as long as those revoked certificates validity period is still in effect. This can be advantageous especially if a CA is issuing a large number of certificates and, potentially, revoking a large number of those certificates. This reduces the possibility of having one huge CRL that certificate verifiers have to download. Instead, issue a number of certificates with one key, renew the CA early into its validity period with a new key, then issue a number of certificates using the new key. In this way, you will reduce the size of the CRL that the certificate verifier has to download when presented with a certificate from an issuing CA.
For more detailed information about planning for renewal and renewing Microsoft certification authorities, refer to the Microsoft Windows Deployment and Resource Kits.
Procedures to renew CAs
For the procedure to renew a root CA, see Renew a root certification authority.
For the procedure to renew a subordinate or intermediate CA, see Renew a subordinate certification authority.