On 2/14/2012 1:09 PM, T. Valent wrote:
Hi!My root-cert will expire in a few months. I'm now planning a migration to renew the certificates. The goal is to ensure a seamless migration without loss of service by updating the servers and clients certificates. Currently I'm lacking a plan how to do the migration. The problem is that I cannot change all certs at a time but must somehow make sure that the client cert can connect to the old and the new server certs so that I can update all client certs first, and once that is completed then update the server certs. I could also do it the other way: Update the server certs first so that they accept connections from both, the new and the old client certificates and once that's done, update all client certs. Here are the details: I'm running a project with a few hundred servers a few thousand clients connecting to these servers. For each (group of) server(s) there is a set of clients that may connect to these servers. When this was set up long time ago the structure was this: root-cert group1-cert (signed with root cert) server1-1 cert (signed with group1-cert) server1-2 cert (optional) client1 cert (signed with group1-cert) group2-cert server2 cert client2 cert [...] All connections are authenticated using certificates. A group1 client can only connect to a group1 server (and not to a group2 server) and the group1 servers will also reject connections from any peer except those with a group1 client certificate. I have generated a new root certificate and I can easily generate new group, server and client certificates but I haven't found a way yet how to do the migration. Is there a way I can create new client certs that can connect to the old AND the new server certs? Help will be appreciated!
I haven't reached that point myself yet, but here is how I would do it: 1. For anything this big, always test the procedures small scale before rolling out for real. 2. Make sure the full distinguished names of root and intermediary certificates are slightly different from the old ones, e.g. by including a version number as an extra OU or similar, but in a place which your servers and clients do not care much about. 3. Issue the new-groupX-cert intermediary certificates with validity starting yesterday (in case of clock skew). 4. Configure each serverX to accept client certificates issued by old-groupX-cert OR new-groupX-cert (most server software can be configured with a list of valid client-cert-issuers and the SSL protocol supports that). 5. Clients can now log in with new OR old certs and are still presented with old-serverX-cert which they still trust. 6. Now clients can get new certificates for themselves and simultaneously get the new certs to trust for the servers (new-root and new-groupX-cert). 7. When all clients in a group have switched to new certificates (and thus trusts both the old and new root), issue and switch to a new serverX cert too, drop the server-side trust of old-groupX-cert and have old-root revoke old-groupX-cert. 8. Try to complete step 7 before old-root expires. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [email protected] Automated List Manager [email protected]
