Eve可以用她的私钥签署一个名称为“a.com”的证书，但 Bob 的浏览器不会接受它。当 Bob 的浏览器验证证书链时，它会验证所有签名，而不仅仅是签名。完整的验证算法很复杂；见标准。在这种情况下，Bob 的浏览器在应用第 6.1.4 节中的 check (k) 时会引起隐喻：Eve 的证书是“版本 3”证书，但不包含Basic Constraints扩展名，或者其Basic Constraints扩展名cA设置为FALSE.

简而言之，虽然认证是一种权力委托，但颁发证书的权力是规定需要显式委托的，默认不做。正如@Terry 所说，商业 CA可以授予子 CA 证书，并将cA标志设置为TRUE，但他们会为此收取很多费用。事实上，他们将通过合同约束子 CA 以遵守 CA 的认证实践声明（参见Verisign的 CPS）。合同义务包括与保险商进行大量大笔资金谈判之类的事情，因此颁发假证书的子 CA Eve 将被 Verisign 的法律报复彻底遗忘。他们没有俘虏。

过去的事情过去不是那样工作的。X.509 的第一个版本不支持扩展，因此客户端必须找到其他方法来验证给定实体是否具有 CA 权力。这很不方便，因为浏览器必须在嵌入不断增长的“允许的子 CA”列表之间做出选择，或者只是信任所有具有 CA 权力的证书（从而允许您的攻击）。请注意，直到 2003 年左右，Internet Explorer 中都存在一个错误：IE 根本没有检查Basic Constraints扩展！当这个被发现时，它立即被修补，当然......

您对证书签名过程的工作方式存在误解。

在大多数情况下，Eve无法使用她从 Verisign 获得的证书签署证书。浏览器将拒绝 Eve 签名的证书。

为了让 Eve 使用她从 Verisign 获得的证书签署证书，她必须获得一个包含基本约束扩展且cA标志设置为的证书TRUE。不用说，这样的证书要贵得多。

可以允许 Eve 签署证书的此类证书a.com有时是可用的，尽管存在很大争议。一些 CA 在颁发此类证书（Trustwave、Turktrust等）方面不太负责，而另一些 CA 则有严格的控制（合同、政策、审计）以防止创建可用于 MiTM 攻击的证书。

例如，GlobalSign 有一种产品理论上可用于中间人攻击，但合同和技术要求以及审计阻止了这种使用（理论上也是如此）。在无法进行技术控制的情况下 - 客户将被审核并具有与独立 CA 相同的技术要求。

创建 MiTM 证书的更大风险是 CA 被黑客入侵（直接或通过受信任的经销商）。它在过去发生过（Comodo，DigiNotar），并且可能会再次发生。

正如特里所说，您从 CA 获得的普通证书无法签署其他证书。

基本上，您不能使用另一个证书签署证书。证书仅包含公钥。

• 证书使用发件人的私钥（以及其他一些参数，具体取决于您使用的标准）进行数字签名。
  • 证书由 VeriSign 使用其私钥签名。您的浏览器使用 VeriSign 的证书（公钥）验证证书。
  • 如果 Eve 想要签署一个证书，她将使用她的私钥，但该证书将被您的浏览器视为无效，因为它在受信任的 CA 列表中没有 Eve 的数字证书。