简短回答：是的，终端实体选择大于 CA 公钥的公钥有一些潜在的好处。

问题并不完全清楚，但我认为您的情况是根或父级使用 1024 位 RSA 密钥（即，最终实体的证书使用 1024 位 RSA 密钥签名），而最终实体使用2048 位 RSA 密钥（即，终端主机认证和使用的公钥是 2048 位 RSA 密钥）。

在这种情况下，我可以看到使用 2048 位最终实体证书而不是 1024 位最终实体证书的两个潜在安全优势：

• 对于可以破解 1024 位 RSA 但不能破解 2048 位 RSA 并且只能窃听但不能（或不愿意）主动篡改连接的攻击者，您是安全的。相比之下，如果您使用 1024 位 RSA 密钥，那么这样的攻击者可以恢复您的 RSA 私钥、窃听连接并解密加密的流量。

• 假设 CA 在未来几年内过渡到 2048 位 RSA（正如许多 CA 和许多浏览器所做的那样），您可以安全地抵御从现在起五年后破坏 1024 位 RSA 但无法破坏 2048 位 RSA 的攻击者要求）。这是因为如果该密钥不再有效，则能够在五年后恢复 CA 的 1024 位签名密钥的攻击者不会因此而获得任何收益。CA 的签名密钥无法帮助攻击者解密他可能访问的任何 SSL 加密流量（甚至不是他很久以前记录的旧流量）。攻击者对 CA 的签名密钥唯一能做的就是签署一个新的伪造证书并使用它对用户发起中间人攻击，但如果 CA 的根证书和 1024 位公钥不再是五年后被浏览器接受，那不会

[此外，现在选择 2048 位密钥并能够继续使用它几年可能会带来一些密钥管理好处，即使您必须更新证书才能这样做，而不是必须更改密钥一两年。需要明确的是，这不是安全利益；这只是一个潜在的后勤好处，具体取决于您发现在未来某个时候必须更改您的密钥有多烦人。]

底线：选择大于 CA 密钥的最终实体密钥可能会有一些好处。但是，我不想声称好处是压倒性的，或者最终实体公钥的大小才是最重要的。面对一个强大的攻击者，他们能够并且愿意发起主动攻击，并且可以在 CA 根证书的有效期内破解 1024 位 RSA，无论您选择什么大小的公钥，您都可能会被淹没。

好像你在问2个问题：

让最终实体证书具有比签名链中的 CA 更大的密钥空间是否有任何好处

我同意其他发布者的观点，即结果好坏参半——但我想将其分解为典型的安全功能：

• 机密性 - 如果您使用最终实体密钥对进行机密性（SSL 设置期间的密钥加密、存储或传输数据的加密） - 那么无论 CA 签名者在做什么，您都将受益于更大的密钥。破解你的加密完全与找到你的私钥（或发现算法的弱点）有关
• 完整性 - 如果您使用最终实体密钥对来签署数据，那么破解您的签名与您的密钥强度有关。但是，完整性检查通常与身份验证检查相结合 - 见下文。

• 身份验证 - 这是问题所在。如果您的 CA 的私钥更容易猜到，您的身份验证/不可否认能力就会减弱。如果由于密钥空间较小，我可以找到您的 CA 的私钥，那么我可以假装是您的 CA，我可以制作一个看起来像您的任意大小的证书和密钥对并且有一个我控制的密钥对。这几乎是在脚上拍摄认证。它不会被受信任的 CA 证书列表捕获，因为攻击者将模拟其中一个已配置的受信任证书。在发现闯入之前很难检测到。此外，撤销 CA 也很痛苦。您应该在每个消费系统中检查最终实体和 CA 链的状态的证书状态检查，或者您必须撤销 CA 颁发的每个有效的最终实体。如果我们谈论的是自签名根证书中的小密钥空间，这将变得更加困难。无法对根进行状态检查。CA 系统将不得不发布一个巨大的公共警告，并让任何依赖方从其受信任的存储中删除根及其所有子 CA。

• 可用性——当我考虑 PKI 中的可用性时，我会考虑使用 PKI 进行身份验证/访问控制，以使服务仅对特权用户可用。鉴于此，可用性与身份验证一样重要。

所以，总结 - 你用证书做什么？如果您仅将其用于机密性和纯粹的完整性-您的情况还不错。但请记住，PKI 保护机制经常混合这些类别。SSL 客户端或服务器身份验证既是一种设置安全通道（机密性）的方式，也是一种审查服务器身份的方式（身份验证）。电子邮件签名既是一种防篡改传输（完整性）的方式，也是一种证明传输来自发件人（身份验证）的方法。它很快就长毛了。

下一个问题...

让我的最终实体比颁发它的 CA 具有更长的有效期是否有益甚至可能？

在我工作过的 PKI 系统中 - 绝对不是 - 最终实体证书不能作为比 CA 证书的生命周期更长的有效期颁发。

然而，从实际经验中退一步，我正在查看 X509 证书的 RFC： http ://www.ietf.org/rfc/rfc3280.txt

Section 6.1.3  Basic Certificate Processing

包括验证链中每个证书的有效日期。

本节是以下内容的一部分：

6.1  Basic Path Validation

   This text describes an algorithm for X.509 path processing.  A
   conformant implementation MUST include an X.509 path processing
   procedure that is functionally equivalent to the external behavior of
   this algorithm.  However, support for some of the certificate
   extensions processed in this algorithm are OPTIONAL for compliant
   implementations.  Clients that do not support these extensions MAY
   omit the corresponding steps in the path validation algorithm.

所以应该对路径中的每个证书（即最终实体、每个签名 CA 和根）都执行此操作

有效性检查不是可选的扩展，它们是证书的必需部分。

如果系统正确地进行路径验证，则对最终实体证书具有更长的有效期应该对您没有好处。我没有看更远，看看是否允许。我相信我测试过的 CA 系统的设置不允许这样做，但我也认为，凭借一定程度的创造力，我可能能够生成打破这种模式的证书。但是请记住，我是在系统管理员权限下进行的，甚至可能是在强化 CA 中不应该提供的白盒测试机制。10 多年前，我也在使用如今已不再市场的 CA 进行此操作 - 里程可能会有所不同。

攻击者可能会尝试进行两种攻击：

• 主动攻击：攻击者在您连接到服务器时干预数据包（可能直到运行他自己的完整假服务器）。为此，攻击者必须能够立即破解其中一个公钥（服务器的密钥或 CA 之一的密钥）。

• 被动攻击：攻击者记录数据包，但不改变它们。之后，攻击者试图破解用于加密的任何密钥，以解开明文数据。对于带有“RSA”密码套件（不是“DHE_RSA”套件）之一的SSL/TLS，破解服务器的 RSA 公钥足以解密整个会话。

重要的一点是，事后破解 CA 的密钥对攻击者没有任何好处（它只对破解后发生的攻击会话有帮助）。但是，破解服务器的密钥本身可能有助于他解密以前记录的会话。因此，服务器密钥的安全约束实际上比 CA 密钥更严格；因此，为服务器本身使用更大的密钥是有意义的。

（“DHE”密码套件仅使用服务器的密钥进行签名，它将问题转移到服务器决定用于实际密钥交换的临时 Diffie-Hellman 密钥。同样，服务器在逻辑上有权使用DH 密钥比它自己的 RSA 密钥或 CA 密钥强。）

如果攻击者希望冒充您的站点，他们可以通过尝试破坏您的最终实体密钥来实现此目的，或者他们可以破坏其中一个签名 CA 密钥，这将允许他们为任何域颁发自己的最终实体证书包括你的。针对这种攻击，证书链与其最薄弱的环节一样强大。

如果攻击者希望从您的站点读取 SSL 加密的流量，则攻击者必须破坏最终实体密钥；破坏 CA 密钥在这里无济于事。如果您担心这种攻击，那么拥有更长的最终实体密钥可能是有意义的。还要记住，这种特殊的攻击可以通过使用临时 DH 密码套件来防止，但会降低性能。

至于拥有比签名证书有效期更长的最终实体证书，那里有几个可能的问题。首先，CA 甚至可能不同意颁发这样的证书；它可能会将有效期截断为其根证书的有效期。其次，即使你获得了这样的证书，一旦链中最早的证书过期，链将无法验证。如果证书由受信任的根直接签名，则可能会有例外。