我在客户端-服务器应用程序中使用SSL证书；客户端和服务器都使用两个即将过期的证书。通常，您只需用新证书替换证书，但由于客户端数量巨大，这不可能同时发生。因此，如果只更新服务器和一部分客户端，其余客户端将无法再进行身份验证。
一个快速的解决方案是用一个简单地忽略证书到期日期的版本来替换二进制文件；客户端的更新可以按顺序进行，只要在证书到期之前完成即可。
我考虑过的长期解决方案：
-
使用Puppet在客户端上推送新证书
- 不幸的是，这是不可行的，因为并非所有客户都将通过Puppet进行管理
-
使用第二组证书
- 如果第一个集合已过期，请使用第二个集合
- 通过这种方式，服务器将有新的证书，一部分客户端将有新证书，其余客户端将有旧证书，但一切正常
-
如果当前证书已过期，客户端将向服务器请求新证书。
还有其他解决方案吗？
我假设您使用SSL证书进行在线SSL连接，如HTTPS或SFTP。
最大的问题是：你还信任并想使用你的服务器端密钥吗！如果是这样，您只需重新颁发具有新到期日期的服务器证书，仍然使用旧密钥，从而延长使用寿命。问题是，你是否仍然信任旧钥匙，或者它是否应该被替换。届时，老客户可能仍会连接到您。。你仍然使用相同的公钥/私钥对，只是为它制作了一个新的"终身版本"证书。(这是大多数公共服务器所做的。)
在服务器端为不同的密钥使用两组活动SSL证书是不可行的，只有当你对客户端的握手过程有很好的控制并且你的服务器应用程序支持它时才有可能。问题是，在SSL协商期间，服务器必须首先发送其证书，并且它可能从客户端获得的唯一指示是在ClientHello期间的ServerName扩展。(假设客户端实际发送了一个)。否则，服务器对另一方将支持或不支持的内容"不知所措"。(还有一些其他扩展可能有助于指示支持的CA证书，但您的客户端应该支持这些扩展)。
第一种对于支持它的客户端来说是最实用的。只需续订他们的证书(也许还有密钥)并推送它们。你已经受够了。
对于其他人来说，更新客户端软件并确保他们生成新密钥，并在需要时(或提前)向服务器请求新证书可能是最好的解决方案。