如何验证TLS证书链

Question

假设TLS证书链的验证。假设该链具有证书and，其中D是根证书，A由B签名，B由C签名，C由D签名。

假设发现中间证书B已经内置到浏览器中。也就是说，检查A，发现它是有效的(并由B签名)，B被内置到浏览器中。

(1)链条的验证是在那里结束，还是一直到D为止？

(2)当服务器向浏览器显示其证书链时，它是同时呈现根证书D，还是只在当前的A中显示？

Answer 1

(1)链条的验证是在那里结束，还是一直到D为止？

它依赖于证书链接引擎(CCE)实现。不同的平台有不同的实现，这些实现可能不支持RFC5280中描述的所有推荐/强制验证逻辑。

证书信任需要以自签名形式表示的链点的结束(我们称之为根CA证书)。由于证书B不是自签名的(由C签名)，所以在获取和验证C和D之前，不能信任and链。因此，这个问题的答案是:链继续验证到根。

如果我们讨论Microsoft实现(只是我熟悉的一个例子)，他们的CCE (尽可能多地)构建一个或多个链，而不执行立即的验证。它们只需获取证书并尝试执行基本规则，将每个证书绑定到链中的正确位置。当构建所有链时，每个链都根据RFC5280中描述的规则进行验证。一旦验证，可能存在多个可信和有效的链。CCE使用自己的选择逻辑从一组链中只选择一条链。

当我们谈到浏览器中的证书存储时，它们习惯于：

1. 建立对特定受信任根CA (可信根CA存储)的信任。这些证书必须以自签名的形式提交.否则，它们不能用作链端点，并且信任也没有建立(即使中间证书安装在根存储区中)。
2. 帮助CCE快速构建链，而不必从internet下载丢失的证书，因为它们在本地可用。有些浏览器完全缺乏处理Authority Information Access扩展的能力，这意味着SSL只能从两个源获取CA证书: SSL握手和本地证书存储。

(2)当服务器向浏览器显示其证书链时，它是同时呈现根证书D，还是只在当前的A中显示？

它依赖于web服务器的实现。来自RFC 5246§7.4.2的参考：

certificate_list --这是一个证书序列(链)。发件人的证书必须放在列表的第一位。以下每一份证书必须直接证明其前面的证书。由于证书验证要求独立分发根密钥，因此可以从链中省略指定根证书颁发机构的自签名证书，前提是远程端必须已经拥有该证书才能在任何情况下对其进行验证。

RFC建议将根CA证书发送到客户端，也可能不会发送。因此，在开发SSL客户端时，您应该预期根证书可能会沿着链发送。两个主要的web服务器: Apache和IIS默认情况下不会在SSL握手期间发送根证书。

Answer 2

1)如果中间证书(B)是可信的--也就是说，它是一个有效的签名证书，没有过期，没有被篡改，也没有被撤销--那么在信任存储区中，TLS客户端就不需要在链上继续进行验证了。

然而，“不篡改”的事情需要有一个可信的证书已经签署了中间证书。现在，中间证书可以是自签名的，就像根证书一样，除了作为到根证书的链的一部分。在这种情况下(假设签名签出)，不需要验证中间证书上面的链。

有些客户甚至可能甚至不检查证书上是否有有效的签名(它在信任存储中，因此理论上是可信任的)，或者它没有被撤销(许多旧浏览器默认没有检查是否撤销证书，假设它们将使用更新的已撤销证书列表更新，而不再在信任存储中)。在实践中，您应该假设这两件事(有效的签名，即使它是自签名，而不是撤销)是由大多数客户端检查。

2)这完全取决于服务器。除了根证书之外，所有服务都是典型的，但是有些服务器发送整个链。如果您使用像Qualys SSLLabs这样的站点，它将向您显示服务器发送的证书。这个站点似乎发送了两个证书--一个用于*.stackexchange.com的通配符叶和一个"Server“中间证书，但没有发送根证书(它是一个DigiCert EV根CA，并对中间证书进行签名)。但是，其他一些站点确实会发送完整的链接；如果这样做，SSLLabs会标记它，但通常这是一种浪费。