Certificate Life Cycle

  • Article

The certificate life cycle includes the following events:

  • CAs are installed and their certificates are issued.

  • Certificates are issued by CAs.

  • Certificates are revoked (as necessary).

  • Certificates are either renewed or allowed to expire.

  • The CAs' certificates are renewed before they expire.

  • The CA is revoked or retired.

Issued certificates expire at the end of their lifetime, but they can be renewed as necessary. You also can renew CAs before the CA's certificate expires to ensure continuous certificate services in your enterprise.

Windows 2000 CAs require nested validity dates for the certificate life cycle. A Windows 2000 CA cannot issue certificates with a lifetime that extends beyond the end date for the CA's certificate validity. If the lifetime specified for a requested certificate type exceeds the expiration date of the CA's certificate, the CA truncates the lifetime of the issued certificate to match the validity end date for the CA's certificate. Therefore, nested validity dates are an important consideration when you are planning the certificate life cycle for Windows 2000 Certificate Services CAs. Third-party CAs might not require nested lifetimes for the certificate life cycle.

The certificate lifetimes of certificates that are issued by enterprise CAs are determined differently than the lifetime of certificates that are issued by stand-alone CAs. An enterprise CA issues certificates with lifetimes that are based on the certificate template for the requested certificate type. A stand-alone CA issues certificates with a lifetime that is determined by system registry settings for the CA. Furthermore, the lifetime of CA certificates is affected by several other factors. In addition, take into account how long private keys can be safely used so that you do not exceed the maximum safe lifetime of the keys.

Nested Validity Dates

Windows 2000 enterprise CAs and stand-alone CAs require nested validity dates for all CA certificates and all issued certificates. For example, if a Windows 2000 root CA's certificate end date is January 2, 2010, no Windows 2000 child CA in the chain below the root can issue a certificate with a date that is past January 2, 2010. If a Windows 2000 intermediate CA has a certificate end date of January 2, 2006, no Windows 2000 child CA can issue certificates with an end date that is past January 2, 2006. If a Windows 2000 issuing CA has a certificate end date of January 2, 2002, no certificate the CA issues can have an end date that is past January 2, 2002.

If a Windows 2000 CA's certificate has an end date of January 2, 2002, and it receives a request to issue a one-year certificate on August 1, 2000, the CA issues the one-year certificate with an end date of July 31, 2001. However, if the CA receives a request to issue a one-year certificate on August 1, 2001, the CA issues the certificate with an end date of January 2, 2002.

A Windows 2000 CA with a certificate life of five years ending on January 2, 2005, can issue one-year certificates until January 2, 2004, or two-year certificates until January 2, 2003. After January 2, 2003, the CA does not issue two-year certificates; it truncates the validity end date to January 2, 2005. Likewise, after January 2, 2004, the CA truncates the validity end date of both one-year and two-year certificates to January 2, 2005.

You usually renew Windows 2000 CAs with new CA certificates before they are constrained by nested validity dates. To avoid the constraints of nested validity dates, deep certification hierarchies with Windows 2000 Certificate Services might require frequent renewals for issuing CAs.

Certificates Issued by Stand-alone Certification Authorities

For stand-alone CAs, the lifetime of issued certificates is determined by the following registry entries:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc
\Configuration\
Stand-aloneCA
\
ValidityPeriod
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc
\Configuration\
Stand-aloneCA
\
ValidityPeriodUnits

caution-iconCaution

Do not use a registry editor to edit the registry directly unless you have no alternative. The registry editors bypass the standard safeguards provided by administrative tools. These safeguards prevent you from entering conflicting settings or settings that are likely to degrade performance or damage your system. Editing the registry directly can have serious, unexpected consequences that can prevent the system from starting and require that you reinstall Windows 2000. To configure or customize Windows 2000, use the programs in Control Panel or Microsoft Management Console (MMC) whenever possible.

Where Stand-aloneCA is the name of the installed CA, the value of ValidityPeriod is either "Days," "Weeks," "Months," or "Years," and ValidityPeriodUnits is the number of days, weeks, months or years that constitute the lifetime of certificates issued by the CA. For example, when the value of ValidityPeriod is "Years" and the decimal value of ValidityPeriodUnits is "2," the CA issues certificates with a lifetime of two years.

By default, stand-alone CAs issue certificates with lifetimes of one year. (The default settings are: ValidityPeriod  = Years and ValidityPeriodUnits  = 1,) To specify another lifetime for certificates that are issued by a stand-alone CA, edit the registry for the stand-alone CA, and enter the appropriate values for ValidityPeriod and ValidityPeriodUnits .

All certificates that the stand-alone CA issues have the lifetime specified by the values of the ValidityPeriod and ValidityPeriodUnits registry entries. Therefore, if you want to issue certificates with different lifetimes, you must deploy either enterprise CAs, multiple stand-alone CAs, or third-party CAs.

Certificates Issued by Enterprise Certification Authorities

For enterprise CAs, the maximum lifetime of certificates that are issued is determined by the settings of ValidityPeriod and ValidityPeriodUnits in the registry. The default settings are: ValidityPeriod  = Years and ValidityPeriodUnits  = 2. Therefore, the maximum lifetime of certificates that are issued by an enterprise CA is two years unless you modify the registry settings.

In addition, the lifetime of each certificate type is determined by its certificate template. The lifetime for many certificate types is one year. However, the following certificate templates specify a lifetime of two years:

  • CEP Encryption (offline request)

  • Enrollment Agent

  • Enrollment Agent (computer)

  • Enrollment Agent (offline request)

  • IPSec

  • IPSec (offline request)

  • Router (offline request)

  • Web Server

The following certificate templates specify a lifetime of five years:

  • Domain Controller

  • Subordinate Certification Authority

These certificates are usually issued for two years (the maximum default lifetime of certificates issued by enterprise CAs). To enable an enterprise CA to issue certificates for five years, you must change the settings of ValidityPeriod and ValidityPeriodUnits for the CA to five years or more.

In addition, you can modify ValidityPeriod and ValidityPeriodUnits of a CA to reduce the maximum lifetime of certificates that it issues. For example, to reduce the maximum lifetime of all certificates issued by a CA to six months, you can change ValidityPeriod to "Month" and ValidityPeriodUnits to "6". You can also deploy custom certificate services to meet special certificate lifetime needs for your organization.

Certification Authorities' Certificates

For enterprise root CAs and enterprise stand-alone root CAs, the CA certificates are installed with a default lifetime of two years. However, during CA installation, you can specify a different lifetime for the CA. You can specify the root CA's lifetime in days, weeks, months, or years. For example, you might specify a root CA lifetime of 20 years because you use a large private key and provide high security for the CA. You might also want to specify short lifetimes of days or weeks when you are testing the deployment of Certificate Services.

During the installation of subordinate CAs, the system enables you to request a subordinate CA certificate from an active parent CA, or you have the option of creating a certificate request file and then submitting the request offline to a parent CA. For online requests from an active CA, when the request is approved, the subordinate CA is issued a subordinate CA certificate automatically by the parent enterprise CA. For offline requests, you must use the Web Enrollment Support pages to submit the certificate request file to the parent CA. After the subordinate CA certificate is issued, you must use the Certification Authority console to install the certification path file to certify and start the CA.

The lifetime of a subordinate CA certificate is determined by the parent CA that approves the certificate request and issues it. If the parent CA is an enterprise CA, the default lifetime of the subordinate CA's certificate is two years, unless the ValidityPeriod and ValidityPeriodUnits values are changed in the registry for the parent CA. You can change the registry to specify a shorter or longer lifetime for certificates that are issued by the parent CA, but the maximum lifetime for subordinate CA certificates is five years as specified by the Subordinate Certification Authority certificate template. If the parent CA is a stand-alone, the lifetime of the subordinate CA's certificate is determined by the values of the ValidityPeriod and ValidityPeriodUnits entries in the registry of the parent CA.

Consider using stand-alone CAs for root and intermediate CAs to provide the most flexibility for defining certificate life cycles. If you specify long lifetimes for CAs and later discover that they are at greater risk than originally anticipated, it is easy to renew CAs in the certification hierarchy with shorter lifetimes as necessary to reduce risk.

Using stand-alone CAs for root and intermediate CAs can provide other benefits as well. If you operate stand-alone CAs offline (not connected to the network) and maintain them in secure physical environments, the risk of attacks is reduced. You also can regulate the installation process to carefully control the CAs that are installed and trusted in the enterprise.

Administering offline certificate requests for both stand-alone root and intermediate CAs is usually cost effective because the CAs are used infrequently to process relatively few certificate requests. You might, however, occasionally connect to the network only as long as necessary to publish CRLs or to process infrequent online certificate requests for subordinate CA certificates.

Example of a Certificate Life Cycle

Table 16.4 describes an example of a certificate life cycle that an organization might plan for Windows 2000 CAs and standard Microsoft CSPs.

Table   16.4 Windows   2000 Certificate Life Cycle

Purpose of Certificate

Certificate Life

Private Key Life

Stand-alone root CA.
(4,096-bit key)

20 years

Renew at least every 10 years to ensure that intermediate CA certificates can be issued with lifetimes of 10 years. Renew by using a new key at least every 20 years.

Stand-alone intermediate CA for all certificates except smart card certificates.
(3,072-bit key)

10 years

Renew at least every 5 years to ensure that child issuing CAs can be issued for a full 5 years. Renew by using a new key at least every 10 years.

Enterprise issuing CA for all certificates except smart card certificates.
(2,048-bit key)

5 years

Renew at least every 3 years to ensure that Web server certificates can be issued for a full 2 years. Renew by using a new key at least every 5 years.

Enterprise issuing CA 2 for smart card certificates.
(2,048-bit key)

5 years

Renew at least every four years to ensure that certificates can be issued for a full year. Renew by using a new key at least every 5 years.

Enterprise issuing CA 3 for all other certificates besides smart cards, secure mail, and secure browser certificates.
(2,048-bit key)

5 years

Renew at least every 4 years to ensure that certificates can be issued for a full year. Renew by using a new key at least every 5 years.

Secure mail and secure browser certificates.

1 year

Renew by using a new key at least every 2 years.

Smart card certificates.
(1,024-bit key)

1 year

Renew by using a new key at least every 2 years.

Administrator certificates.
(1,024-bit key)

1 year

Renew by using a new key at least every 2 years.

Secure Web server certificates.
(1,024-bit key)

2 years

Renew by using a new key at least every 2 years.

Business partners' users certificates for an extranet.
(512-bit key)

6 months

Renew by using a new key at least every year.

note-iconNote

The certificate life cycle described in Table 16.4 is provided only as an example and is not intended to be a recommendation. Your certificate life cycle can differ from the example in many ways, including the length of certificate lifetimes, key lengths, and key lifetimes.

In Table 16.4, all certificates are issued by Windows 2000 CAs except for the certificates for the business partners' users (for the extranet), which are issued by the CA of the business partner. The certificates of the business partner are trusted in the extranet domain by using CTLs. Stand-alone CAs are used to provide flexible lifetimes for CAs where this is appropriate. Renewing certificates with new keys limits the time that keys are in use and reduces the risk of key compromise.

Because of the constraints of nested validity dates, when you allow CAs to issue certificates with truncated lifetimes, the certificates that are issued must be renewed more frequently as the end validity date of the CA's certificate is approached. Therefore, CAs are usually renewed before the certificates that are issued by the CA have truncated lifetimes. You also renew certificates with new keys before their maximum safe lifetime are exceeded. To reduce risks for private keys, you might also renew certificates with new keys each time the certificate is renewed if it is feasible to do so.

The deeper the certification hierarchy, the shorter the certificate lifetimes become. Plan your certificate life cycles to avoid excessively short certificate lifetimes and certificate renewal cycles.

General Considerations for Key Lifetimes

There is no simple formula for determining maximum private key lifetimes. The lifetimes you choose depend on various risk factors, such as the following:

  • The length of private keys for certificates. In general, longer keys support longer key lifetimes.

  • Security provided for private keys by the CSPs. In general, hardware-based CSPs provide more security and can support longer private key lifetimes than software-based CSPs.

  • Security provided for CAs and their private keys. In general, the more secure the CA and its private key, the longer the safe CA lifetime. For example, you might improve the security for CAs by operating them offline and storing them in locked vaults or data centers.

  • The strength of the cryptographic technology used for cryptographic operations. Some cryptographic technologies provide stronger security, as well as support for stronger cryptographic algorithms. For example, you might use smart cards for logging on by users or FORTEZZA Crypto Cards for secure mail and secure Web browsers. In general, stronger cryptographic technology supports longer key lifetimes.

  • The risk of attack on the CA certification chain. These risks depend primarily on how secure your enterprise is, how valuable the network resources protected by your public key security applications are, and how much launching attacks would cost the attackers. In general, high risks of attack require longer CA private keys and shorter key lifetimes.

To further reduce the risk of a compromised private key, the private key and public key sets for certificates might be renewed each time the certificates are renewed, instead of waiting for the maximum key lifetime. However, for some hardware-based CSPs, renewing certificates with new key sets is not feasible either because of key storage limits or because key generation takes a long time.

When you install a Windows 2000 CA, you can select the Advanced options check box on the first page of the Windows Components wizard, with which you can specify the key length that is used with the CA's certificate. You can select CA key lengths from 384 bits to 16,384 bits. In general, the longer the key, the longer the safe key lifetime. The use of keys that are at least 1,024 bits long is recommended for CAs.

Consider using the largest keys that are practical to use for CAs to provide the maximum protection feasible without degrading CA performance. Keep in mind that very large keys can place a high load on computer processors and might require excessive amounts of time for signing operations. Test proposed CA key lengths in the lab and pilot programs before you deploy CAs to your production environment.

For more information about the risks associated with private keys, see "Cryptography for Network and Information Security" in this book.

When you renew certificates by using the Microsoft CSPs, you also can renew the certificate's private key and public key set. In general, the longer the key set is in use, the higher the risk that the key might become compromised. Establish maximum allowable key lifetimes, and renew certificates with new key sets before these limits are exceeded.