问基于HTTPS、客户证书和自定义CA的系统设计

EN

首先，让我们注意，每个服务器名义上都有两个密钥和相应的证书。一种是用作SSL意义上的服务器(当浏览器或另一台服务器连接到机器时)，另一种是用作客户端(当机器本身连接到另一台服务器时)。您可以将密钥(和证书)安排为相同的，但这可以添加一些约束。非对称密钥对可以用于密钥交换或数字签名，但并非所有算法都支持两者；此外，证书本身还可以通过其Key Usage扩展进一步限制只使用签名或只进行密钥交换。在SSL中，当使用一个基本的基于RSA的密码套件(例如非常常见的TLS_RSA_WITH_AES_128_CBC_SHA)时，服务器密钥用于密钥交换(即在客户端随机生成的秘密密钥的非对称加密)，但是基于证书的客户端身份验证必须使用签名。

因此，如果您希望每个服务器拥有一个私钥，则必须安排下列任一项：

• 服务器密钥具有RSA类型，证书允许加密和签名。
• 证书允许(至少)签名，您将服务器配置为只使用"DHE“密码套件(密钥交换部分随后使用服务器动态生成的短暂Diffie-Hellman密钥对完成，服务器密钥仅用于签名)。

一般来说，DHE密码套件是推荐的，因为它们提供了完全前向保密：即使攻击者窃取了服务器私钥的副本，通过有线交换的数据也不能随后解密。

如果不需要浏览器警告，则不应将服务器IP地址放在subjectDN中，而应放在服务器DNS名称中。浏览器(以及更一般的所有HTTPS客户端)在连接到服务器时，希望在服务器证书中找到预期的服务器名称，即URL中出现的服务器名称。他们希望在Subject Alt Name扩展(类型为dNSName)中找到它，或者，如果完全缺少这样的扩展，则在subject DN的公共名称中找到它。此查找仅用于名称，而不是IP地址。这在RFC 2818第3.1节中有描述。

在证书中查找IP地址没有概念上的问题；只是现有的浏览器没有这样做。所以还是坚持名字吧。此外，当基础设施迁移时，名称很方便( IP可以更改，但是名称将保持不变，因此不需要新的证书颁发)。

话虽如此，对于你的确切问题：

只要您对证书的有效性感到满意，就可以使用证书，但请注意以下几点：

• 随着时间的推移，技术进步了，因此，被认为是稳健的关键可能会在一段时间后变得不那么健壮。因此，您可能希望限制密钥生存期，以便需要一些操作，从而迫使您定期重新考虑您的密钥大小选择。如果你使用2048位RSA，那么在可预见的未来，即在未来20年左右，你应该是好的(除此之外，没有预见性，只有推测)。
• 如果您选择2038年1月18日以后的有效期结束日期，2038年问题可能意味着一些互操作性问题。
• 您希望有一个方便的过程来解决密钥折衷的情况(例如，被窃取的备份磁带)，如果证书生存期超过一周，“等待证书过期”就不太可行了。见下文。

CA对于安全至关重要，所以谨慎的部署应该是将其放到脱机计算机上。没有网络意味着根本没有可能的远程黑客，这是一件好事。但是，正如上面所解释的，您需要“某种东西”来应对妥协的情况，这可以是以下两种情况之一：

• 你只颁发很短的证书，例如每周一张新的证书，有效期只有10天。每个服务器每周都收到一个新的证书。如果私钥被偷，窃贼只有十天的时间玩它，因为之后你不会为这个特定的钥匙颁发新的证书。
• 您使用证书撤销列表：CA定期发布(例如每周)一个新的签名CRL，其中包含已撤销证书的序列号。客户端(浏览器和其他服务器)将下载该CRL以检查服务器证书是否仍然良好。这在数学上相当于短期证书的情况。

短命证书的优点是不让浏览器进入循环(只有服务器才需要知道它)，但是SSL实现更有可能支持CRL。要支持CRL，您需要在证书中添加一个CRL Distribution Point扩展。

无论哪种方式，您的CA都必须定期将一些数据元素推送到远程服务器，无论它们是更新的证书还是CRL。这与脱机CA的概念不一致。有些解决方案意味着物理上的单向连接(有些人使用10基T以太网，只有一对电线连接；我也曾经部署过一个系统，在音频链路上编码CRL，因为音频插孔是电子单向的)。

我希望您的大多数客户将CA放在同一台计算机上，而不是他们的第一台服务器，然后忘记它，并在他们的服务器被黑客入侵时感到非常抱歉。