证书链如何呈现给客户？

Question

  

如何将证书链呈现给客户？

我已经了解到，root用户存储区仅存储自签名证书（“ root”证书）。

让A> B> ...> R为证书，其中A> B表示B签名{{ 1}}的证书代表。并且A是“根”证书。

具有证书R的服务器如何将其证书提交给在其根存储中具有A的客户端？

服务器是否将整个链R> A> ...（不是B）发送给客户端？还是只发送证书R，如果客户端没有A> ...在其根存储中“某处”存储了B，则验证失败了吗？

Answer 1

为了说明这一点，让我们看一下未来的标准TLS 1.3，因为在当前的较低版本中情况会类似。

第4.4.2节处理证书交换。它以结尾。服务器的certificate_list务必始终为非空。但是上面的文本解释了这种结构：

  

certificate_list

     

这是CertificateEntry的序列（链）         结构，每个结构包含一个证书和一组证书         扩展程序。

及更高版本：

  

发件人的证书必须位于第一个      列表中的CertificateEntry。以下每个证书      直接证明紧接其之前的那个。因为      证书验证要求分发信任锚      独立地，指定信任锚的证书可以是      如果知道支持的对等方，则从链中省略      拥有任何遗漏的证书。

这直接回答了您的问题：在这种情况下，服务器应该发送A，B等...，但可以省略根最终证书R（我认为这很常见。

关于结构中证书的顺序，文档告诉我们：

  

注意：在TLS 1.3之前，每个都需要“ certificate_list”排序      证书以证明紧接其之前的证书；然而，      一些实现允许一些灵活性。服务器有时      发送当前和已弃用的中间件以进行过渡      用途，而其他的只是配置不正确，但是这些      尽管如此，案例仍可得到正确验证。最大化      兼容性，所有实现都应准备好处理      潜在的无关证书和任意命令      TLS版本，但最终实体证书除外      必须是第一位。

对于客户端来说，如果需要发送其证书，则是相同的：它将需要将所有中间证书（如果有）发送到服务器，该服务器通常仅配置（顶部）CA列表。