I was reading a CPS/CP for a CA, and it mentioned that there's a possibility after rekey that you can still use the old key to sign CRLs of the old end user certificates verified by the old CA certificate, the only case where I see that would be applicable is if a browser for example doesn't add the new CA certificate in its trust store for a period of time and so it can't verify the new CRLs, is that the case?

1 Answer 1


Correct. There is no reason to invalidate all issued certificates when a CA decides it needs to re-key - that would simply cause chaos. As such, all those extant certificates need to be managed throughout their life-cycle. In order for clients to continue to carry out revocation checking on any of these certificates the CA must continue to sign a CRL with the original key-pair; as well as a sign a new CRL with the new key-pair.

The CA will now be signing multiple CRLs and clients will need to access the correct version. Therefore the crlDistributionPoint extension on certificates signed by the new key-pair will have a different URL to the certificates signed by the original pair. For example, Microsoft's ADCS appends a (n) to the filename for each re-key, where n increases by one each time.

  • This hassle is also the reason why OCSP is preferable in this instance. You don't need to manage multiple revocation lists with multiple keys. The OCSP response can just be signed with whatever key the client understands.
    – user163495
    Jun 13, 2019 at 11:34
  • @MechMK1 - the OCSP response certificate has to be signed by the CA which issued the certificate being queried - RFC6960 Section - and not any key the client understands. If the CA re-keys, it will need to issue a new OCSP signing certificate to the responders. Jun 13, 2019 at 12:51

You must log in to answer this question.

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