0

I'm using SSL certificates in a client-server application; both the client and the server are using 2 certificates that will expire soon. Normally, you'd just replace the certificates with new ones, but this cannot happen at once because of the huge numbers of clients. So, if only the servers and a part of the clients are updated, the rest of the clients won't be able to authenticate anymore.

A quick fix is to replace the binaries with a version which simply disregards expiry date of the certificates; the update of the clients can be done sequentially, as long as it will finish before the certificates expire.

Long term solutions I thought about:

  1. use Puppet to push new certificates on clients

    • unfortunately, not viable because not all clients are/will be managed via Puppet

  2. use a second set of certificates

    • if first set has expired, use the second one
    • in this manner, server will have new certificates, a part of clients will have new certificates and the rest of the clients will have old certificates, but everything works

  3. client requests a new certificate from the server, if the current one has expired.

Are there any other solutions?

tshepang
  • 12,111
  • 21
  • 91
  • 136
Florin M
  • 179
  • 2
  • 9

1 Answers1

0

I assume you use the SSL certificates for an online SSL connection, like HTTPS, or SFTP.

The big question is: Do you still trust and want to use your server-side key! If so you can just re-issue the server certificate with a new expiration date still using the old key and thus extending the lifetime. The question is, if you still trust the old key or if it should be replaced. Old clients may still connect to you at that point.. You are still using the same public / private key pair, just made a new 'lifetime version' of the certificate for it. (That is what most public servers do..)

Using two sets of active SSL certificates for different keys on the server side is not really viable and only possible if you have good control over the handshake process on the client side and your server application supports it. The issue is that during an SSL negotiation, the server has to send its certificate first and the only indication it might get from the client is a ServerName extension during the ClientHello. (Assuming the client actually sends one). Otherwise the server is 'at a loss' on what the other side will or will not support. (There are some other extensions that might help for in indicating supported CA certificates, but your clients should support those).

The first is the most practical for the clients that do support it. Just renew their certificates (and perhaps keys) and push them. And you are done with those.

For the others, updating the client software and making sure they generate a new key and request a new certificate from the server when they need it (or in advance) might be the best solution.

David R.
  • 796
  • 7
  • 6