Renewing Microsoft Certificate Services Root Certificate

Question

We currently have Microsoft Enterprise Certificate Server installed on a domain member machine which issues 1 year certificates to users for authenticating to VPN.

We'd like to start issuing web server certificates from our CA to secure Dell Open Manage (a systems management application) and also Microsoft RDP. Because we have quite a few servers (100+) and I haven't found a way to automate certificate installation (note installation - not deployment - I know how to automatically deploy) we're considering issuing certificates for the lifetime of the server. Most of our servers are used for 10 years or less so we'd want 10-15 year certificates.

As I understand, CA's can't issue certificates longer than they themselves are valid. Thus if we wanted to issue 10 year SSL certificates our root CA certificate would need to be valid at least 11 years but practically probably 15-20 years.

Additionally I understand that the longer the duration of the certificate the more susceptible the private key is to compromise and thus the desire to use a longer key length for longer certificates.

I'm considering renewing the root certificate for a longer duration but I have the following questions:

1) Is generating a root certificate 15-20 years within best practices? Again I understand ideally we would issue certificates for a shorter duration - but the manual labor involved with installing said certificates each year isn't trivial thus the desire to use a longer length - so long as doing so is reasonably safe

2) Should we use 4096 key length for the root CA or can we use a shorter key? Some reading I've done suggests some network devices won't support certificates longer than 2048 bits.

3) When renewing the root certificate we have the option of reusing its existing key pair or generating a new key pair. I understand generating a new key pair is better from a security standpoint but do if we do that will our existing issued certificates continue to function without needing to make any changes?

Thanks
Brad

Answer 1

Root certificates (strictly speaking, "trust anchors") are supposed to be long-lived; as you notice, changing a root certificate is expensive because it must not be done lightly: that certificate concentrates the whole security of your certificates and what they are used for. For interoperability, you probably want to keep the validity dates below year 2038, because there are some (many) systems out there which internally encode dates as a count of seconds since January 1st, 1970, over a signed 32-bit integer. On a specific date of year 2038, the count will wrap around, into negative values, and hilarity ensues. This is the binary equivalent of the Y2K bug. Hopefully, when we reach that fateful date, most architectures will have switched to a 64-bit model where this issue will not occur for a long long time; or at least to a count over an unsigned 32-bit integer, which buys an extra 68 years. (Y2K turned out to be quite minor, so there is no reason to panic. Yet.)

For RSA keys, 2048 bits ought to be enough for long term security. This is, of course, a bet on future technology and science, hence there is no guarantee. Visit this site for a complete treatment of recommended key lengths. Alternatively, see if you can use ECDSA for your root certificate: almost all ECDSA implementations support the "P-521" standard curve, which offers "521-bit security", supposedly equivalent to a 15360-bit-or-so RSA key (i.e. no worry for a long time).

If your new root certificate uses the same key and the same name, then it will match previously issued certificates, and things will be fine. If you change the key and/or the name, then you will have to issue new certificates. Possibly, if you use intermediate CA certificates, then only those will have to be reissued. The "normal" way of managing a root key rollover is to define the new root, insert it in all verifier devices without removing the old root; after a few years, when all certificates which relate to the old root have expired, you can remove it from the verifier systems.

Of course, the main reason why you would want to change the root is that you believe that the key has been around for too long; reusing the same key defeats the purpose. Note that the root is, by nature, unique: there is one private key to worry about, located in a single place, normally a hardened tamper-resistant HSM (Hardware Security Module). The point of such a HSM is that the key cannot be stolen without you knowing it. So, as long as you use a big enough key to begin with, you will not have to change the key -- or, if you do, then you have to do it urgently. At that point, root validity dates are moot: if the root key is stolen, you want the new key to be deployed now (at least, by the end of the week), not within the next three years. Hence, the "current practice" is to make a long-lived root with a big key, and to set the root end-of-validity a few years beyond your own predicted retirement date (so that this will be someone's else problem).