I'm trying to understand how CA's operate. One question that came to my mind is that, according to my intuition, a single private key should have a limited amount of certificates it can issue. Given this,

How often do CA's renew the keys, and under what circumstances (number of certificates issued, time, etc.)?

As an additional question, in the case that a CA needs to renew its key pair, what happens with the previous certificates that are still valid? are these signed again under the new key?

Thanks in advance.

4 Answers 4


This is a great chance to flesh-out the basics of how CAs work. I will assume that we're talking about root CAs here, since renewing a subordinate CA is not really a big deal.

How often do CA's renew the keys, and under what circumstances (number of certificates issued, time, etc.)?

I will re-phrase this question:

What factors increase an attacker's likelihood of cracking the CA's private key?

Assuming we're not talking about hacks, backdoors, insider threat, etc, and only talking about cracking based on public information, then the answer is: the choice of algorithm, key size, and amount of time.

The calculation goes something like this: say we choose RSA-4096, then we'd look up the runtime of the best known attacks against RSA, look up costs for renting that amount of computing power on Amazon, do some Moore's Law calculations and take a guess how long it would take an attacker to break it. It turns out for RSA and ECC that the best known attacks only need the public key; a signature leaks zero information about the private key, so seeing lots of signatures does not help.

Note that this will not be true for some of the post-quantum signature algorithms. In particular with hash-based signatures [article1], [article2], the private keys are essentially huge collections of single-use keys where each signature reveals a private key. Once the worlf switches to post-quantum crypto, your question will become much more relevant.

In the case that a CA needs to renew its key pair, what happens with the previous certificates that are still valid? are these signed again under the new key?

This is indeed a fundamental problem with the way CAs are designed. I have seen it be handled in two different ways:

  1. The CA simply won't issue certs that outlive itself. Say you have a CA that issues 1-year certs. When the CA itself has less than a year on it they will stand up a new issuing CA. The old CA is still around for revocation checks and stuff, but no longer issues new certificates.

  2. Cross-certify the old CA with the new one so that when validating a cert issued by the old CA, it will chain to the current CA. This is a bit hacky because there is technically an expired CA in the chain. Most TLS engines do not support this kind of thing, so I have only seen it in closed environments like corporate email or ID badge systems where you have more control over the clients.

Because of the disruption of rolling over a root CA, you want it to be valid for a long time. A quick look through my browser's root certs shows 15 year certs, 20 year certs, and even some 30 year certs.

  • Thanks for the great answer! It's very clear, and also very illustrative with the examples you handed with respect to the second question. I understand the calculations you mention, but in practice, how much time is this usually? That is, in the history of the CA's what is usually the time that a specific key is active? By the way, I think that your claim about pq-signatures holds in particular for Hash-based signatures, but it's not something inherent of post-quantum signature schemes.
    – Daniel
    Aug 7, 2017 at 8:42
  • At the bottom I give the number of years that is typical for a root CA. Intermediate / issuing CAs tend to only be 1 - 5 years, but that has more to do with administrative convenience. Aug 7, 2017 at 13:46
  • Alright, that makes sense! thank you so much for the information
    – Daniel
    Aug 8, 2017 at 8:43

I don't think there's any technical limit, in terms of x509 standard as published by ISO/IEC/ITU-T (I don't have a copy of ISO 9594-8 to confirm this, if anyone does, can you please check this?). However, according to RFC 5280: "serial number MUST be a positive integer" and "Conforming CAs MUST NOT use serialNumber values longer than 20 octets", so a single CA certificate can issue 2159-1 direct descendant certificates with unique serial numbers conforming to RFC 5280.

In practice, each CA often have implementation limits on their infrastructure that further limits what they'll actually be able to generate. However, non-CA implementations may treat the serial number field as a BLOB, so they would be able to handle even oversized or incorrectly encoded serial numbers.

In terms of managing business risks, it is indeed wise for a CA to limit the number of certificates that a single root or intermediate certificates can issue. This is so that if, for any reasons, they have to revoke the root or intermediate certificate, they would only need to reissue a smaller number of certificates rather than what happened to Symantec, in which a problem with one of its subsidiaries causes the certificates for their entire user base to be revoked, as there's no way for browsers to distinguish between certificates issues by the problematic subsidiaries compared to the certificates issued by compliant subsidiaries.

  • +1 for a concrete limit. Though 2^159 is a huge number; we're approaching the energy limit of the sun to issue them all. (see some math in a recent answer of mine) Aug 7, 2017 at 2:35
  • Thanks for the comprehensive answer! From what I can understand it seems that the only reason to change a key is due to some limitations on infrastructure or convenience (when reissuing certificates). Isn't there a security compromise in issuing many certificates?
    – Daniel
    Aug 7, 2017 at 8:26
  • The main reasons to change a CA private key is key expiry, as well as compromise (whether it's real or suspected). As far as publicly available knowledge, all other things being equal, issuing more certificates doesn't make one certificate authority easier to compromise than another.
    – Lie Ryan
    Aug 10, 2017 at 10:25

Essentially you are asking how much known plain text is needed in order to get to the private key when doing an RSA or ECDSA signature, because you have the certificate and hash (input signature algorithm) and the signature (output). There is currently no practically feasible attack against these signatures when using common key sizes. This means trying to get the private key of the CA from the certificates it issued is no problem in practice, no matter how many certificates where issued.

Still, (sub-)CA certificates will be renewed from time to time too because they were expired or because the signature algorithm used to sign the CA is deemed unsafe.

  • Very concise and clear! thank you so much. Yes, you hit the point: I was making some kind of relation between the number of message/signature pairs and the feasibility of cracking the scheme. However, as you mentioned (and as I have seen from the other answers) it seems that keys get renewed for practicality rather than security matters. In this case, how often does this occurs? For example, I would expect the root CA to renew its key less often than its subordinate CA's, am I correct?
    – Daniel
    Aug 7, 2017 at 8:45
  • I don't think there is a general rule. But is common that root CA are very well protected, i.e. the key is protected by hardware (smart card or similar) and the root CA is only used offline to create sub-CA. These sub-CA are then used to create the leaf certificates, are more at risk and will be replaced more often than the root CA. Sometimes there is even another level of sub-CA to reduce the risk further. For example take google.com which has a life time of 3 month. It is issued by a sub-CA with a life time of 18 month which is issued by a root CA with a life time of 20 years. Aug 7, 2017 at 9:05
  • Alright! thanks, I get the point, but what do you mean with "google.com has a life time of 3 months"? Anyway, I am very interested in the particular example you just mentioned, could you please give me a reference about how certain CAs manage this "renewal time" with respect to the root CA and the sub-CAs? I have tried to google it but I have found nothing explicitly (or I just don't know how to google it correctly.)
    – Daniel
    Aug 7, 2017 at 9:10
  • @Daniel: a certificate has a start date and an end date, after which it will no longer be accepted as valid. The life time is the time in between these. Aug 7, 2017 at 10:06
  • Thanks, that's what I thought, I just was surprised about such a short life time, is that usual?
    – Daniel
    Aug 7, 2017 at 12:52

How often do CA's renew the keys, and under what circumstances (number of certificates issued, time, etc.)?

the question makes no sense. CA key renewal period depends on different factors. For instance, key size, key security, CRL size. There is no direct correlation between CA key renewal and a number of signed certificates.

what happens with the previous certificates that are still valid? are these signed again under the new key?

no, previously issued certificates are not re-signed by new CA keys. Technically, CA key renewal implies new CA with "accidentally" matching name.

You must log in to answer this question.

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