5

I have the following issue: we use TLS with client cert verification to identify clients to a service. To this end, we have created our own self-signed certificate authority, which does nothing but sign certificates for these clients and verify their validity. We replicate this setup in our development environment.

The development CA has just expired, so no new certificates can be issued in our development environment. We have quite a bit of time left on the production CA, but I would like to figure out if there is a smooth process for migrating from an expired CA certificate to a new non-expired one without breaking existing certificates.

The naive solution is, generate a new CA cert and replace the old one. However, I believe this will cause existing clients to fail validation.

I've done a bit of googling and reading, and I THINK what I need to do is..

  1. Create a new CA cert and use that for signing new client certs
  2. Create some sort of "combo" cert which includes both the new CA cert and old CA cert and use that for validating clients (bridge? chain?)

Point 2 is where I'm failing to find detailed documentation. Additional general questions I have:

  1. Is it possible to set the "combo" cert up in a way that it can be used for both issuing new certs and validating both new and old certs? Like, is it possible to indicate "this certificate is really 2 certificates, and the new one is the one that should be used for signing new clients?" This is strictly a practical concern - fewer files to keep track of.
  2. Should I just avoid combining anything at all and just use both CA certs in the trust pool of the validating software? I guess this goes back to the first question..

Sorry about the vague language, I'm purposefully avoiding specific x509 terms because I'm afraid I'll use them incorrectly and confuse the question.

2
  • I guess you should use both CA certs in the trust pool. Note that if you still trust the keys on the clients / CA that you could build a new cert around them (although this might also be a good time to up your key size or algorithms if that's required). Feb 8, 2015 at 1:56
  • @Maarten: My gut feeling would be that questions like this fall into the overlap area between Crypto.SE and Security.SE, and are therefore on topic at both sites. Of course, you're likely to get somewhat different answers depending on which site you ask them on. Feb 8, 2015 at 17:43

2 Answers 2

4

Signing is done with the private key. The matching public key to verify the signature is inside the certificate. You can renew a certificate (change the expiration) while re-using the existing key pair. Thus the signature will still be valid even if the certificate itself got changed.

For upgrading the quality of the key you create a new key and create a new CA certificate based on this. New certificates will then be issued by this new CA certificate but the old CA is still usable to verify existing certificates and can be thrown away once all these older certificates expired.

2

A proper PKI should also cover aspects like certificate updates for all certificates, including the ones from CAs and the root CA.

Of course you can use the old certificate for verification and use a new one to be used for signing and verification of new ones. But basically that means, you are running 2 PKIs in parallel, with no connection etc.

As a general rule, a CA should never issue an expiration date beyond its own, so that at the expiration date of the root, all its issued client certificated are also invalid. And that means, that once the root certificate runs out, you should have no reason to keep the old certificate around at all.

If you want to solve your issue with as little impact on the users as possible, you should develop a proper renewal strategy for clients and the root certificate immediately and deploy it before the current system breaks. One such system would in fact be to have a grace period, where the old certificate is still valid, but renewals are done with a new certificate.

1
  • 1
    Are there any good resources you would recommend on "graceful" renewal? Want to get a better idea about the trust assumptions involved. For example, let's say I decide to gracefully phase out the old CA and replace it with a new CA and I want the clients to continue working. Is it acceptable for me to issue new certificates to clients from the new CA based on the fact that they have been validated using the old CA?
    – Mikhail P
    Feb 13, 2015 at 19:10

You must log in to answer this question.

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