首先让我们注意，您的每台服务器名义上都有两个密钥和相应的证书。一种是用作 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）中找到它，或者，如果完全没有这样的扩展名，则在主题 DN 的通用名称中找到它。此查找仅针对名称，而不针对 IP 地址。这在RFC 2818 的第 3.1 节中有描述。

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

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

只要您愿意，证书有效期就可以，但有以下注意事项：

• 技术随着时间的推移而进步，因此被认为是强大的密钥可能会在一段时间后变得不那么强大。因此，您可能希望限制密钥的生命周期，以便需要一些操作，从而迫使您定期重新考虑您的密钥大小选择。如果您使用 2048 位 RSA，那么在可预见的未来，即未来 20 年左右（更进一步，没有预见，只有推测），您应该会很好。

• 如果您选择 2038年1 月 18 日之后的有效期结束日期，则2038 年问题可能意味着一些互操作性问题。

• 您需要一个方便的过程来解决密钥泄露的情况（例如，被盗的备份磁带），如果证书的生命周期超过一周，“等待证书过期”就不是很可行。见下文。

CA对安全至关重要，因此谨慎的部署是将其放在离线机器上。根本没有网络意味着不可能进行远程黑客攻击，这是一件好事。但是，如上所述，您需要“一些东西”来应对妥协情况，这可能是以下两种情况之一：

• 您只颁发非常短暂的证书，例如每周一个新的证书只有 10 天有效。每台服务器每周都会收到一个新证书。如果私钥被盗，小偷只有十天的时间来玩它，因为之后您将不会为该特定密钥颁发新证书。

• 您使用证书吊销列表：CA 定期发布（例如每周）一个新的签名 CRL，其中包含被吊销证书的序列号。客户端（浏览器和其他服务器）将下载该 CRL 以检查服务器证书是否仍然有效。这在数学上等同于具有短期证书的场景。

短期证书具有使浏览器远离循环的优势（只有服务器需要知道它），但 CRL 更有可能被 SSL 实现开箱即用地支持。要支持 CRL，您需要CRL Distribution Point在证书中添加扩展名。

无论哪种方式，您的 CA 都必须定期将一些数据元素推送到远程服务器，无论是更新证书还是 CRL。这与离线 CA 的概念不一致。一些解决方案意味着物理上的单向链路（有些人使用 10baseT 以太网，只连接了一对电线；我也曾经部署过一个系统，其中 CRL 通过音频链路进行编码，因为线路输出音频插孔是电子接口-大大地）。

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