I am surprised that I couldn't find one concrete example of how to do root certificate rotation. For example:

  • Root CA has 2 years validity period
  • Intermediate CA has 9 months validity period
  • leaf certificate has a 3 months validity period

The renwal/replace time are:

  • Root CA is going to be replaced every 1 year
  • Intermediate CA is going to be replaced every 6 months
  • leaf certificate is going to be renewed every 2 months

This gives

  • 1 month buffer for service to renew its certificate before the certificate expires.
  • 3 months buffer for intermediate CA to sign new service certificate. By the time the old intermediate CA expire, all the old issued certificates are expired as well.
  • 1 year buffer to distribute the new root certificates to client. We want to give enough time for clients to pull the new root certificate before the old one expires.


  • We have root 1 and root 2 overlapped for 1 year, when should we start signing new CSR using root 2 certificate?

If the one year overlapped time is just for cert distribution, by the time root 1 expired, all clients should already have root 2 trusted. However, by the time root 1 expires, we haven't signed any new server certificates with root 2. It means when the time root 1 expires, all the services will be down. I guess we will need to ensure all services are using cert from root 2 before we can retire root 1? and we also have to ensure all clients have root 2 key before issuing server certificates using root 2? I think that makes sense but in terms of timeline, how should we managed that? In the 1 year overlapped time, maybe we can do 6 months distribution time, and 6 months signing time. so by the time root 1 retire, everything will be running on root 2 already?

And if we are using private CA, (lets say AWS private CA) , do we need to implement a service to ensure things above will happen?

Given that we own all the clients and servers.

1 Answer 1


I would start from the bottom and work my way up to the root.

Your leaf certificates will be valid for 2 months, that means your current intermediate must still be valid for at least 2 months when issuing a new certificate. In other words, you need a new intermediate in place and ready to use every 4 months (given that an intermediate is valid for 6 months).

You could fit 6 intermediates within the lifetime of one root (24/4 = 6). However, you cannot issue leaf certificates for the old root after its lifetime exceeded 22 months (because the leaf would then be valid longer than the root).

In your scenario, I would create a new root every year, distribute it immediately, and start using it after 4 months.

But why is the lifetime of your root certificates so short? The purpose of root certificates is to have a long certificate lifetime (10 to 20 years) and a root is typically kept offline with the private key stored securely in an HSM or a smart card and only brought online to sign a new intermediate or a CRL. There is no need to rotate a root certificate often.

You could then create relatively short lived intermediates and rotate them often if that is your requirement. It is easy to distribute intermediates (they get sent to the client along with the leaf certificate during a TLS hanshake), but burdensome to distribute and deploy a new root (because this has to happen out of band).

  • Thanks for your reply, I think that makes sense :) I will do a quick summary. Root cert will have 2 years validity, when it hit 1 year mark, we will generate a second root cert and gives 4 months time to distribute. After the 4 months marks (1.4yr), we will start using the new root key to sign intermediate CA. IntermediateCA has 6 months validity, so in the worst case, the intermediate ca signed by the first root key will be expired in 1 yr 10 months, which also leaves 2 months for the latest server cert to be expired. Jun 30, 2020 at 7:41
  • 1
    And to answer your other questions, a lot of people set root cert to 10-20 years, that makes sense if you are a public CA. But for private CA, if you design the system well, it should also be able to handle root cert rotation effectively. Having 10 years long root ca cert for private CA will cost big troubles in 10 years time (no matters how many tests you performed, something is gonna go wrong). And I am using private CA from AWS, so it is easier for an attacker to compromise my AWS root account to issue root cert instead of compromising the AWS HSM. Jun 30, 2020 at 7:49

You must log in to answer this question.

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