了解 SSL 证书签名

信息安全 tls 证书 证书颁发机构
2021-09-01 20:47:12

我试图了解 SSL 证书和签名以及信任链是如何工作的。

我知道root CAs并且它们用于签署intermediate CAs颁发给网站的最终证书。我也了解信任链是如何工作的,并且因为X.com签署的证书是由颁发它的中间证书签署的,而中间证书是由根 CA 签署的,所以我可以确信我正在连接到X.com.

我的问题是,这条链延伸了多长时间?我不能用它X.com来为另一个域签署证书,比如Y.com. 如果没有,为什么不呢?如果是,我看不到签名的目的。

4个回答

为了被接受为其他证书的颁发者,必须将 CA 证书标记为:它们必须包含标志设置为的Basic Constraints扩展名如果客户端(例如 Web 浏览器)看到声称的服务器证书链,其中“X.com”证书未标记为 CA,用作中间 CA,则客户端将拒绝该链,在应用标准证书验证算法,在第 6.1.4 节,步骤 (k):cATRUE

  (k)  If certificate i is a version 3 certificate, verify that the
       basicConstraints extension is present and that cA is set to
       TRUE.  (If certificate i is a version 1 or version 2
       certificate, then the application MUST either verify that
       certificate i is a CA certificate through out-of-band means
       or reject the certificate.  Conforming implementations may
       choose to reject all version 1 and version 2 intermediate
       certificates.)

请注意有关“版本 1”和“版本 2”证书的注释。现代 X.509 证书是“版本 3”(它们的version字段包含 2,而不是 0 或 1)。X.509 格式的早期版本没有扩展空间,因此没有Basic Constraints. 您担心的明显漏洞,任何证书所有者都可以充当 CA,确实很明显。但人们花了几年时间才赶上来。

幸运的是,所有当前的 SSL 实现都将 v1 和 v2 证书视为“绝对非 CA”,就像缺少Basic Constraints扩展的 v3 证书一样。

与此类似,直到大约 2003 年(如果我没记错的话),Internet Explorer 都没有检查cA标志……这确实是一个严重的问题,发现后立即修复。它说了很多关于 X.509 的内容,但很长一段时间以来没有人实际测试过它,因为 IE 早在 1996 年就已经支持 SSL 并且 v3 证书在 1999 年初标准化(因此,正如 Web 事物的典型特征,它们已经当时已部署,并且该标准更像是现有实践的文档而不是其他任何东西)。


至于您的具体问题:这条链延伸了多长时间在 X.509 标准中,对于链长度没有内在限制,只要链中的所有证书都被适当地标记为 CA(可能最后一个除外)并且具有适当的签名并且证书中的所有字段都匹配为他们应该。然而,认证是信任委托,当委托过多时,信任会迅速稀释。因此,过长的链强烈表明整个 PKI 过程已经变坏了。

此外,在某些实现中,长链可能会达到内部限制。链构建(准备待验证的潜在链的操作)可能会变得昂贵(使用特制的证书,对于给定的链长度,它可能具有阶乘成本),因此实现必须包括一些保护机制,这通常是内部最大链长度. 实际遇到的链的长度为 2 到 4 个证书(即一个根,最多三个中间 CA,然后是最终实体证书)。我自己的代码倾向于拒绝超过 8 个证书的链,而根据我的经验,这种任意限制从来都不是问题。

当根 CA 为中间 CA 签署证书时,签署的证书有一个特殊字段集(特别是 Basic Constraints extension 中的证书颁发机构标志),将其指定为 CA 证书。为域签名的证书(如您从 CA 获得的那样)没有设置此字段,因此您的浏览器不会将它们视为返回根 CA 的可信证书链。

这个链条能延伸多久?

没有指定限制,但客户端(浏览器、邮件程序等)可能对他们愿意遵循的跃点数有一些内部限制。

我不能使用 X.com 为另一个域签署证书,比如 Y.com。如果没有,为什么不呢?如果是,我看不到签名的目的。

不,因为X.com' 的证书未标记为签名证书。

或者更确切地说:是的,你可以,底层技术不会阻止你这样做。但是浏览器被编程为检查CA: true所有签名和中间证书的基本约束,如果不是真的,则不会信任签名。

说服 CA 为您签署中间证书并非易事,因为他们将自己的声誉押在您不会签署任何不应该签署的任何东西的断言上。不小的保证。

遗憾的是,出于安全考虑,X.com无法签署 Y.com。举个例子:

  1. Mallory 正试图对 Alice 和 Bob 执行 MITM 攻击。他拥有由 Verisign 为 Z.com 签署的有效证书。
  2. Alice 将 X.com 的有效证书发送给 Bob,由 Verisign 签名。
  3. Mallory 截获该连接,用他的 Z.com 证书签署 X.com 证书并将其发送给 bob。
  4. 现在,Mallory 可以解密来自 Bob 的所有数据,因为他拥有他发送的证书的私钥,由 Z.com 签名。