My understanding about SSL/TLS for HTTPS is that servers send their certificates to browsers and browser attempt to decrypt them using trusted CA public keys that are already presented in their store. Also our certificates are limited to an expiration date (mostly because of security).

Do Certificate Authorities need to renew their RSA keys from time to time due to security considerations?

  • 1
    $\begingroup$ TL;DR: Yes they do, however this happens much less often than the end user has to do it. More details to follow tomorrow (time to sleep for me here). $\endgroup$ – SEJPM Dec 23 '16 at 23:45
  • $\begingroup$ Hey, SEJPM. I'm a little bit sleepover tonight. Anyway the way you explain details worth to wait another 24 hours ;) $\endgroup$ – madz Dec 24 '16 at 0:06
  • 2
    $\begingroup$ Note: certificates are not decrypted in any way, they are verified. Decryption with a public key - if such a thing exists - is not the same as signature verification. More information here $\endgroup$ – Maarten Bodewes Dec 24 '16 at 0:49
  • $\begingroup$ @MaartenBodewes I studied the link your mentioned and actually I did not know about different padding schema for signing and encrypting. So +1 for you there. But broadly speaking, I still believe that signing is encrypting with private key and to verify signature, the public key of CA should be involved $\endgroup$ – madz Dec 24 '16 at 18:46
  • 1
    $\begingroup$ You can believe whatever you want, but "servers send their certificates to browsers and browsers attempt to decrypt them" is absolute nonsense. Certificates are certainly not encrypted, I can view their contents without issue even if I do not possess the public key of the CA. Note that you cannot directly encrypt with an ECDSA private key and that the same modular exponentiation operation in PKCS#1 has been explicitly named differently for signing and authentication. $\endgroup$ – Maarten Bodewes Dec 24 '16 at 19:16

To understand why CAs need to rotate their RSA keys less often, let's first investigate why end-users have to rotate their keys / certificate every few years.

There are three main reasons why end-users have to renew their keys / why certificates have a limited life-span.

  • To keep CRLs somewhat small. Expired certificates don't need to be put onto CRLs because they're invalid anyways, this the CRLs can be "constant-sized". Obviously CAs aren't hit by this because you always have an explicit list of trusted CAs.
  • To enforce technology renewal. From time-to-time technology changes and becomes potentially unsafe. Certificate renewal usually forces you to upgrade to more secure technologies (like RSA-2048, SHA-2, ...). The CAs are hit by this, but not because of expiry dates but rather because of pressure from the browsers. However they usually tend to have a long grace period where they put their new certs (not neccessarily with new keys) into the trust stores and gradually remove the old certs.
  • To allow CAs to earn money. When your certificate expires, you have to buy a new one from the CAs which brings them money. So obviously they want to limit certificate validity. Obviously CAs aren't hit by this because renewing CA keys is a lot of work and procedures and thus will be avoided at (nearly) all costs.

So the main reasons why CAs renew their keys seems to be that they have to upgrade key-length and the the main reasons why they have to renew their certificates is outdated hash functions (but in this case they usually keep on using the keys).

Now there are two more reasons why CAs have to renew keys / certs (without being put out of business due to a breach):

| improve this answer | |
  • 1
    $\begingroup$ I'd add: CA business is sold/bought/merged and new owner wants/needs to change names, e.g. Symantec-formerly-Verisign $\endgroup$ – dave_thompson_085 Dec 25 '16 at 8:05

Yes that could happen, but usually it doesn't happen frequently that CA certs are replaced because of security considerations.

Root certificates - the top level certificates - usually have a very long validity period. Replacing a root certificate is a out-of-band process. For instance, for browsers it means putting it into the default certificate store distributed within the browser installation. As they are commonly only used to create the CA certificates below them, they can be securely stored in a safe somewhere (all the more reason to use a secure, up to date browser). Even MD5 certificates may still be secure if the signed certificates are only created internally within the CA.

Of course it might be that certificates need to be replaced earlier than the "valid-to" date. For instance the signature or hash algorithms may need to be replaced or it is suspected that the key has leaked. For any other certificates than CA certificates the old certificates can be marked invalid in a CRL (Certificate Revocation List) or through OCSP (Online Certificate Status Protocol). CA certificates can be part of a chain that lead to the trusted root certificate; they do not have to be distributed with browsers, they can be received and verified during authentication.

As CA certificates may sign end user certificates (or other intermediate CA certificates) that are from a semi-trusted source there is a higher need to make sure that the signature algorithms supported by the certificate are secure. Of course CA certificates are more likely to be kept secure than end user certificates, so the (expected) loss of the private key should happen less often. If the security practices of the CA itself are sufficiently lacking there may not be any time to renew certificates, by the way.

So yes, CA certificates must be renewed from time to time, because there are security related issues or because they are near the date of expiry (usually there is some overlap between certificates validity period to allow everybody to switch).

| improve this answer | |
  • $\begingroup$ Thank you Maarten. Good answer, both the answers were good and I kind of not sure to choose one of them for the answer. I decided to choose SEJPM's answer because of it seems to be a little more structural and you +1 $\endgroup$ – madz Dec 24 '16 at 18:51
  • 1
    $\begingroup$ @pendrive There is nothing wrong with SEJPM's answer, so I can hardly complain about that :). He already said he was going to answer, but this subject is broad enough for a few answers, so I thought of adding my own. $\endgroup$ – Maarten Bodewes Dec 24 '16 at 19:19
  • $\begingroup$ Also your profile picture is awesome ;) $\endgroup$ – madz Dec 24 '16 at 19:33

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.