Operating a Windows PKI: Certification Authority Certificate Lifecycle and Renewals
Certification Authority Certificate Lifecycle and Renewals
In this blog post I am going to discuss managing the Lifecycle for CA Certificates as well as cover the actual process to renew CA Certificates.
Number of Tiers
If an organization is looking to deploy a new PKI, we usually first discuss the type of overall design in terms of hierarchy. There are typically 3 types of hierarchies that we see deployed. There is the Single Tier PKI Hierarchy which consists of a single CA that is both a Root and Issuing CA. There are several drawbacks with a Single Tier Hierarchy including the fact that it is not a very secure or scalable solution. Then there is a Two Tier PKI Hierarchy. A Two Tier PKI Hierarchy is a more secure solution since the Root CA is kept offline, which prevents it from being compromised via the network. A Two Tier Hierarchy also is much more scalable since you can always add additional Issuing CAs to the hierarchy to meet the organization’s needs. There is also a Three Tier Hierarchy. A Three Tier hierarchy is typically used in very large organizations that either require a more complex solution or need the 3 tiers to meet some security objective.
CA Certificate and End-entity Certificate Validity Periods
Typically a Two Tier hierarchy meets most organizations needs in terms of both security and scalability. So, for the remainder of this blog posting I will be discussing certificate lifetimes in relation to a Two Tier PKI Hierarchy. Once a customer has decided the overall type of design, we then start to discuss the various configuration options for the Certification Authorities. One of those discussions is around the lifetime of the CA Certificates and RSA key pairs. When discussing these lifetime there are several things to take in to consideration. Typically, I discuss the certificate lifetimes based on a “bottom to top” approach. My first question typically is: How long of a lifetime do you plan on issuing end-entity certificates for? A lot of organizations are familiar with getting 1 year or 2 year certificates from a 3rd party CA. So, most customers typically plan on issuing end-entity certs for 2 years. If you are pretty comfortable with issuing certificates for 1 or 2 years that does have some implication for the lifetimes of the CA certificates and RSA key pairs.
The implication for CA certificate lifetimes and RSA key pairs is around enrollment. If you are going to want to issue certificates for either 1 or 2 years, you will most likely want to have your Issuing CA be valid for at least double that period of time. So, this would lead to a discussion on potentially have either a 4 or 5 year lifetime for the Issuing CA Certificate and RSA key pairs. So, why should the lifetime of the CA certificate be twice the lifetime of the issued certificates? Well, the answer it turns out is pretty simple. An Issuing CA cannot issue certificates that are valid for longer than its own lifetime.
So, based on this information we know that the Issuing CA will need to have at least a lifetime of 2 years if we are issuing two year certs. However, if you make the CA only valid for 2 years you will only be able to issue 2 year certs on the first day that the Issuing CA is created. This is because on the following day the CAs certificate lifetime will be 1 day short of two years. So, at this point you would only be able to issue certs that are valid for 1 day short of 2 years. So, in this scenario as the CAs lifetime gets shorter and shorter the validity period of issued certificates gets shorter as well.
So, in order to give the CA a long enough validity period to actually be useful we typically make the Issuing CAs cert valid for at least twice the lifetime of issued certificates. Using the same example of issuing 1 and 2 year certificates we can clearly see that making the CA certificate valid for 4 or 5 years will give us a decent amount of time before the CA certificate needs to be renewed. However, you will still eventually run into the situation as described above, where the CA can no longer issue certificates for the full intended lifecycle. So, how do we handle this? What we do? The answer shortly.
When having the discussion around CA certificate lifetimes one of the other questions I have is: Are there situations that may come up where you may have the need to issue certificates for more than 2 years? And it turns out for a lot of organizations there are situations where issuing 3, 4, or even 5 year end-entity certificates make sense. These situations typically involve devices that require a great deal of administrative effort to both request a certificate and then install the certificate once it is issued. Some examples are non-domain joined Windows machines, network appliances, laptops or mobile devices for remote workers. In many situations, organizations may either not have the staffing to replace certificates on these devices every 1 or 2 years, or may not find it financially feasible to do so. In these types of situations you may increase the lifetime of end-entity certificates to reduce the administrative or financial burden that comes with replacing these certificates more often.
If you are going to issue certificates let’s say that are valid for up to 5 years, again you need to consider implementing a CAs whose certificates lifetime is twice or more than twice the lifetime of issued certificates. This design typically forces organizations to consider having Issuing CAs whose certificate validity period is 10 Years. So, now that an organization has decided that it’s issuing CA certificate is going to be valid for 10 years, what about the Root CA? Well for pretty much the same reason as discussed previously the Root CAs certificate validity period is going to be at least twice that of the Issuing CA. This usually leads to the decision to have a Root CA, whose certificate is valid for a period of 20 years.
CA Certificate Renewals
Let’s continue to use the scenario of have a Root CA valid for 20 Years, an Issuing CA valid for 10 years, and issuing end-entity certificates that have a validity period for up to 5 years. So, once my Issuing CA certificate exceeds 5 years in age, I am going to run into the issue where I am no longer able to issue 5 year certificates. How do we handle this situation? In order to provide adequate lifetime for the CA to issue full term certificates, we renew the Issuing CA certificate at it’s half-life.
Below is a graphic that illustrates the CA Certificate Lifecycle (click graphic to expand):
So, remember this example outlined in the graphic above is of a Two Tier PKI Hierarchy with an Offline Root CA, and an Issuing CA. Below is the timing of the CA Certificate Renewals:
- At t + 5 years, the Issuing CA certificate is renewed with the same key pair, this renewal is to facilitate issuing end-entity certificates for their full life cycle. When the Issuing CA certificate is renewed there will be a new CA certificate with the same key pair. Since, the same key pair is being used there still is only one CRL file generated by the CA.
- At t + 10 years the Issuing CA certificate will be renewed with a new key pair. This action enforces the 10 year lifetime of the RSA key pair as agreed to when designing the PKI and PKI security. This will create a new CA certificate with a new key pair. This will also force the CA to generate a new CRL file, since there is a new key pair. A CRL signed by the “old” key pair will continue to be generated as long as the CA certificate associated with the “old” key pair is still time valid.
- At t + 10 years the Root CA certificate is renewed with the same key pair. This renewal is to facilitate issuing, subordinate CA certificates for their full lifetime. A new Root CA certificate will be created with the same key pair. Since the key pair is the same, the CA will continue to publish 1 CRL.
- At t + 15 years, the Issuing CA certificate is renewed with the same key pair, this renewal is to facilitate issuing end-entity certificates for their full life cycle. When the Issuing CA certificate is renewed there will be a new CA certificate with the same key pair.
- At t + 20 years, the Root CA Certificate is renewed with a new key pair, this enforces the lifetime of the RSA key pair. This action enforces the 10 year lifetime of the RSA key pair as agreed to when designing the PKI and PKI security. This will also force the CA to generate a new CRL file, since there is a new key pair. A CRL signed by the “old” key pair will continue to be generated as long as the CA certificate associated with the “old” key pair is still time valid.
Summary
The purpose of his blog posting was to give a better understanding of when CA Certificates are renewed and why. In my next posting, I will cover some additional considerations for CA Certificate Renewal and cover the steps necessary to renew a CA Certificate.
-Chris
Comments
- Anonymous
April 16, 2015
There are some effects that CA Certificate Renewal has on OCSP. OCSP provides revocation checking information