What is best practice in renewing certification authorities? I mean when should I renew certification authority?

For example, suppose I have the following setup: 1. Root CA with validity of 30 years 2. Sub CA with validity of 20 years issued by Root CA

When renewing certificate of Sub CA after 20 years, it can't have another 20 years because of Root CA certificate would expire before, so in that case new Sub CA would have validity of 10 years.

Or should I renew Root CA 10 years before expiring old certificate and start issuing certificates from this new Root CA?

Or another approach can be to issue new Sub CA 10 years before its expiration and start issuing end entity certificates from the new Sub CA after.

I would like to get a deeper insight into rules how are such situations managed in real life. What should I be looking for to manage certification authorities correctly and renew its certificate in time?

EDIT to have a better understanding:

How would you manage renewing of certification authority with validity of 5 years and issuing end entity certificates with validity 3 years?

What would you do and when in order to have a smooth process transparent to end users?

  • 2
    The real question is more why do you need certificates signed by you that are good for 10+ years? Feb 22, 2016 at 21:28
  • It doesn't matter how long. The above is just an example. Another could be issuing CA with validity of 5 years and issuing end entity certificates for 3 years. Feb 23, 2016 at 19:32
  • Then the answer is really more about your relationship with upstream. Either the browser maker in the case of a root CA that's packaged with the browser, or the root CA that signs your intermediate certificate. As M'vy points out, this isn't really a technical question, but a business one. Root CAs must have a valid root CA for as long as they think a browser will remain un-updated. Feb 23, 2016 at 19:47

3 Answers 3


I think the most important thing to consider is the Root CA lifespan.

Why do we have a Root CA? Because we trust the Root CA and we want to trust things signed by said Root CA.

Why do we have a Sub CA? Because we don't want to use the Root CA every time we want to sign something (because it's safer to just put the private key in cold storage). So we sign a Sub CA (or intermediate) at a shorter lifespan so we have a trustworthy Cert that we can use to sign with but is also not as long lasting in case it is compromised.

Why do we trust the Root CA? Because we've all agreed to trust it.

So, the real question is how often do you want to ask people to trust a new Root Cert? The longer the lifespan, the more dangerous it is if compromised. The shorter the lifespan, the more often you have to ask people to trust a Root Cert.

A Root Cert cannot have its expiry extended.


There is no concept of Root CA renewal (or certificate renewal for what matters), except in a business meaning. Each certificate is a new one, which may or may not reuse the same private/public keys.

When you Root CA is nearly expired, you should create a new one and do the process to have it included in whatever root CA keyring you rely on.

If you are issuing certificates for clients, you should ensure to have a proper cycle of renewal and start issuing from the new CA chain when the validity period of your client cert would exceed the old root CA lifespan.

If the Root CA cert is inserted in time in the certificate repositories in time, the transition will be transparent.


The relevatn PKI standard RFC5280 applies the shell model for certificate validation, meaning that for any signature (and thus certificate) to be valid, any certificate in the signer's chain has to be valid, too.

That means, that after 20 years time, your new Sub CA must not be valid for more than 10 years and any end entity certificates signed by it must not have a notAfter date after the root or subCAs expiration date.

To ease the transition to a new subCA or root certificate (which will use a new keypair), it is good practice to create a cross certificate. That is a certificate having the same entries as the old but signed by the new one. Say you create a new root certificate. Than you would create an intermediate certificate containing the public key and subject (and extensions) of your old root certificate signed by the new one. That way, all old certificates can be succesfully validated by either of the two roots used as a trust anchor. If you do this procedure well in advance (~ 1-2 years), you will have enough time to deploy your new root to all software products and machines needed without creating any disruption to the users.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.