证书链如何呈现给客户端？
我了解到根存储仅存储自签名证书（“根”证书）。
设A>B>...>R 为证书，其中A>B 表示B 分别签署A 的证书。 R 是“根”证书。
具有证书A 的服务器如何将其证书提供给在其根存储中具有R 的客户端？
服务器是否将整个链A>B>...（不是R）发送给客户端？还是它只发送证书A，这样验证失败，如果不是，客户端将B>...存储在“某处”和R在其根存储中？
【问题讨论】：
标签： ssl web certificate ssl-certificate
为了说明问题，让我们看看未来的标准，TLS 1.3，因为在当前的较低版本中情况将类似。
第 4.4.2 节处理证书交换。它以服务器的证书列表必须始终为非空结尾。但上面的文字解释了这种结构：
证书列表
这是 CertificateEntry 的序列（链） 结构，每个都包含一个证书和一组 扩展。
及以后：
发件人的证书必须放在第一位 列表中的证书条目。以下每个证书应该 直接证明前一个。因为 证书验证要求分发信任锚 独立地，指定信任锚的证书可以是 从链中省略，前提是支持的对等点已知 拥有任何遗漏的证书。
这直接回答了您的问题：在这种情况下，服务器应该发送A、B 等...但可以省略根最终证书R（我认为这是常见的）。
关于结构中证书的顺序，文档告诉我们：
注意：在 TLS 1.3 之前，每个都需要“certificate_list”排序 证明紧接其前一者的证明书；然而， 一些实现允许一些灵活性。服务器有时 发送当前和不推荐使用的过渡中间体 目的，而其他的只是配置不正确，但这些 尽管如此，仍可以正确验证案例。对于最大 兼容性，所有实现都应该准备好处理 来自任何潜在的无关证书和任意排序 TLS 版本，最终实体证书除外 必须是第一个。
客户端也一样，如果它需要发送其证书：它需要将所有中间证书（如果有）发送到服务器，服务器通常只配置一个（顶部）CA 列表。
【讨论】：
Because certificate validation requires that trust anchors be distributed independently, a certificate that specifies a trust anchor MAY be omitted from the chain 是什么意思？什么是信任锚？