Smooth root certificate rotation

Question

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.

Questions:

• 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.

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).