当服务器将其证书发送给客户端时，它实际上会发送一个证书链，以便客户端更容易验证服务器证书（客户端不需要完全使用该链，但实际上，大多数客户端将使用链和没有其他）。这在SSL/TLS 标准第 7.4.2 节中进行了描述，特别是这段启发性的摘录：

发件人的证书必须在列表中排在第一位。后面的每个证书必须直接证明它前面的证书。因为证书验证要求根密钥是独立分发的，所以可以从链中省略指定根证书颁发机构的自签名证书，假设远程端必须已经拥有它才能在任何情况下验证它。

由于这是“可能”的情况（“可能”、“必须”、“应该”...... RFC 中的术语在RFC 2119中有非常精确的含义），因此允许服务器包含根证书（又名“信任锚” ") 在链中，或省略它。有些服务器包含它，有些则没有。一个典型的客户端实现，意图准确使用发送的链，将首先尝试在其信任库中查找链证书；否则，它将尝试在其信任库中找到“最后一个”链证书的颁发者。因此，无论哪种方式，这都是符合标准的，并且应该可以工作。

（关于链顺序有一个小的混淆来源。在真正的X.509中，链是从信任锚到最终实体证书排序的。SSL/TLS“证书”消息以相反的顺序编码，结束-实体证书，它首先限定服务器本身。这里，我在 SSL/TLS 术语中使用“最后一个”，而不是 X.509。）

关于在链中发送根的唯一不好的事情是它不必要地使用了一些网络带宽。每个连接大约 1 kB 数据，其中包括完整的握手。在客户端（Web 浏览器）和服务器之间的典型会话中，只有一个连接属于该类型；来自客户端的其他连接将使用基于初始握手的“缩写握手”，并且根本不使用证书。对于许多连续的 HTTP 请求，每个连接都将保持活动状态。所以根发送隐含的网络开销很小。

这意味着站点提供的证书包括证书链的根证书（证书链接到其颁发者证书的链，根是其自己的颁发者的证书）。

由于证书只有在其链的根证书（或中间证书）被客户端明确信任时才受信任，因此不需要提供根证书：如果它是受信任的，则客户端已经拥有它。顺便说一句，该报告通过“信任存储”的注释进一步表明了这一点。

我不会认为这是一个警告的原因，也许只是一个提示。考虑到他们对证书的 100% 评级，ssltest 似乎也很高兴。

可能有相反的利用方式：流氓站点提供伪造的根证书，错误的客户端误认为是受信任的，从而导致客户端信任该站点。不过，此类客户端的用户无论如何都会遇到麻烦。