0

我在客户端-服务器应用程序中使用 SSL 证书；客户端和服务器都使用 2 个即将过期的证书。通常，您只需用新证书替换证书，但这不能立即发生，因为客户数量众多。因此，如果仅更新服务器和部分客户端，则其余客户端将无法再进行身份验证。

一个快速的解决方法是用一个简单地忽略证书到期日期的版本替换二进制文件；客户端的更新可以按顺序进行，只要在证书到期之前完成即可。

我想到的长期解决方案：

  1. 使用 Puppet 在客户端推送新证书

    • 不幸的是，不可行，因为并非所有客户端都/将通过 Puppet 进行管理

  2. 使用第二组证书

    • 如果第一组已过期，请使用第二组
    • 这样，服务器将拥有新证书，部分客户端将拥有新证书，其余客户端将拥有旧证书，但一切正常

  3. 如果当前证书已过期，客户端将向服务器请求新证书。

还有其他解决方案吗？

4

1 回答 1

0

我假设您使用 SSL 证书进行在线 SSL 连接，例如 HTTPS 或 SFTP。

最大的问题是：您是否仍然信任并想要使用您的服务器端密钥！如果是这样，您可以使用旧密钥重新颁发具有新到期日期的服务器证书，从而延长使用寿命。问题是，您是否仍然信任旧密钥或者是否应该更换它。那时旧客户端可能仍会连接到您。您仍在使用相同的公钥/私钥对，只是为它制作了新的“终身版本”证书。（这是大多数公共服务器所做的......）

在服务器端为不同的密钥使用两组活动 SSL 证书实际上并不可行，只有在您对客户端的握手过程有很好的控制并且您的服务器应用程序支持它时才有可能。问题在于，在 SSL 协商期间，服务器必须首先发送其证书，并且它可能从客户端获得的唯一指示是 ClientHello 期间的 ServerName 扩展。（假设客户端实际上发送了一个）。否则，服务器对对方将支持或不支持的内容“不知所措”。（还有一些其他扩展可能有助于指示支持的 CA 证书，但您的客户应该支持这些）。

对于支持它的客户来说，第一个是最实用的。只需更新他们的证书（可能还有密钥）并推送它们。你已经完成了这些。

对于其他人，更新客户端软件并确保他们生成新密钥并在需要时（或提前）从服务器请求新证书可能是最佳解决方案。

于 2012-12-14T12:06:23.970 回答