2

I'm planning to implement a new PKI with 2 tiers of CAs. I'll have end entity certificates with a lifetime of up to 5 years. This means my Issuing CA should be valid for 10 years, in order to be able to issue certificates with a validity of 5 years, after 5 years.

This blog recommends to renew the Issuing CA Certificate after 5 years, using the same private key and to renew the Issuing CA Certificate after 10 years, using a new private key. But doing so means, I have end entity certificates circulating for up to 15 years in my network, which were issued by the same private key.

Wouldn't it be better (more secure and even better to manage) to simply renew CA certs always after half of the lifetime using a new private key? Or is there any downside?

2 Answers 2

1

Five years is a long time in Information Security. Ten years will see the security world decide that some algorithms and keys are too easily compromised. I have a client who had implemented SHA1 hashes in each tier in order to support unpatched Windows XP using a PKI environment that was built within the last four years. We had to rehash each CA's certificate with SHA2 well before a new key or certificate would have been required. Plans change.

You should have plenty of time to research and decide on whether simply renewing or rekeying a certificate is appropriate at each stage. I don't think it's a bad plan to rekey since better, more accepted algorithms (or longer keys) will most likely exist when that span of years has past. The big hurdle with this approach is testing every application that relies on your PKI before rekeying or changing algorithms.

If you work in a Microsoft Windows environment, this is a great resource (although out of print and often expensive): http://www.goodreads.com/book/show/2075482.Windows_Server_2008_PKI_and_Certificate_Security

1

Your question about when / how to renew the CA key is a good one, but I'm afraid that it doesn't have a generic answer; it depends on which applications are consuming those certificates and how they expect a CA to behave as it approaches its end-of-life.

One thing that is universally true is that end-entity certs should never outlive any CA in their issuing chain because zombie certs like that are un-revokable, so any "overlapping" of CA key validity periods essentially means running two CAs:

  1. When the CA cert gets to within end_entity_lifetime of expiry, make a new CA key and self-signed cert.

  2. Cross-certify the old and new CA certs.

  3. Have your CA maintain two sets of CRL / OSCP / CMP services: old certs handled with the old key, new certs handled with the new key.

Pros:

  • End-entities and 3rd-party applications know that only one cert will ever be issued per CA key, and it will be valid until the key is retired. They don't have to worry about querying / updating the CA cert (really convenient for offline, cert-pinning, or cache-dependent applications).
  • End-entities issued from the old and new CA keys can trust each other through the cross-certification link certs.
  • Applications wanting to validate an end-entity cert can still follow the CRL / OCSP info in the cert right up to the expiry of the CA key because the CA is continuing to publish CRLs with the old key.
  • For applications that are aware of link certs, doing a CA key rollover is more secure because you can extend trust from one key to the next, rather than needing to cold-trust the new CA key.

Cons:

  • More complex to manage because you essentially double the number of active CAs.
  • Not all applications are aware of link-certs, so you have to manage compatibility.

Re-issuing a root cert for the same key solves some of these problems, but not all. In particular, it breaks cert pinning based on the cert hash, and it means attackers have a longer window to brute-force the key. That said, this clearly does get done in practice, so I must be missing something...


Summary: I'm not sure there's a "right answer" here. Depending on which applications are consuming your certs, the decision may already be made for you.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .