根 CA 证书可以位于证书路径的中间吗？

Question

我制作了一个连接到网站（tls）并将证书链保存到文件的程序。

有时来自网站的证书链看起来与我的预期不同。

此证书链之一由 Sectigo(ex Comodo) CA 颁发。

我认为“AddTrust External CA Root”应该位于链的最后一个证书中，但位于其链中的第二个证书中。（请看下面的证书链部分）

$ openssl  s_client -showcerts -connect adblockplus.org:443
CONNECTED(00000003)
depth=3 C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Root
verify return:1
depth=2 C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority
verify return:1
depth=1 C = GB, ST = Greater Manchester, L = Salford, O = Sectigo Limited, CN = Sectigo RSA Extended Validation Secure Server CA
verify return:1
depth=0 serialNumber = HRB 73508, jurisdictionC = DE, businessCategory = Private Organization, C = DE, postalCode = 50825, ST = Nordrhein-Westfalen, L = K\C3\B6ln, street = Lichtstra\C3\9Fe 25, O = Eyeo GmbH, OU = COMODO EV SSL, CN = www.adblockplus.org
verify return:1

---
Certificate chain
 0 s:/serialNumber=HRB 73508/jurisdictionC=DE/businessCategory=Private Organization/C=DE/postalCode=50825/ST=Nordrhein-Westfalen/L=K\xC3\xB6ln/street=Lichtstra\xC3\x9Fe 25/O=Eyeo GmbH/OU=COMODO EV SSL/CN=www.adblockplus.org
   i:/C=GB/ST=Greater Manchester/L=Salford/O=Sectigo Limited/CN=Sectigo RSA Extended Validation Secure Server CA
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
 1 s:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
   i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
 2 s:/C=US/ST=New Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA Certification Authority
   i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
 3 s:/C=GB/ST=Greater Manchester/L=Salford/O=Sectigo Limited/CN=Sectigo RSA Extended Validation Secure Server CA
   i:/C=US/ST=New Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA Certification Authority
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
---
Server certificate
subject=/serialNumber=HRB 73508/jurisdictionC=DE/businessCategory=Private Organization/C=DE/postalCode=50825/ST=Nordrhein-Westfalen/L=K\xC3\xB6ln/street=Lichtstra\xC3\x9Fe 25/O=Eyeo GmbH/OU=COMODO EV SSL/CN=www.adblockplus.org
issuer=/C=GB/ST=Greater Manchester/L=Salford/O=Sectigo Limited/CN=Sectigo RSA Extended Validation Secure Server CA

我的问题是：

1. 这种情况正常吗？
2. 网络服务器（这次是adblockplus）是否在制作证书路径？
3. 如何确定有效的证书路径？

欢迎任何 cmets。谢谢

Answer 1

TLS-was-SSL 服务器应该在握手中以正确的顺序发送证书链，但有些不这样做，包括 OpenSSL 在内的大多数客户端仍会正确处理它，通过匹配 issuer=subject 名称，只要叶子（最终实体）证书是first。注意验证过程的痕迹：

depth=3 C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Root
verify return:1
depth=2 C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority
verify return:1
depth=1 C = GB, ST = Greater Manchester, L = Salford, O = Sectigo Limited, CN = Sectigo RSA Extended Validation Secure Server CA
verify return:1
depth=0 serialNumber = HRB 73508, jurisdictionC = DE, businessCategory = Private Organization, C = DE, postalCode = 50825, ST = Nordrhein-Westfalen, L = K\C3\B6ln, street = Lichtstra\C3\9Fe 25, O = Eyeo GmbH, OU = COMODO EV SSL, CN = www.adblockplus.org
verify return:1

您可以看到证书以正确的从上到下的顺序使用，即使它们没有以正确的从下到上的顺序接收 .

这种不当行为很常见，TLS 1.3 已更改为正式允许它。比较RFC 5246 7.4.2 中的 TLS 1.2：

certificate_list ... 发件人的 证书必须排在列表的首位。以下每一个 证书必须直接证明它之前的证书。因为 证书验证要求分发根密钥 独立地，指定根的自签名证书 证书颁发机构可以从链中省略，在 假设远端必须已经拥有它才能 无论如何都要验证它。

到RFC 8446 4.4.2 中的 TLS 1.3，添加了重点：

... 发件人的证书必须排在第一位 列表中的证书条目。以下每个证书应该 直接证明前一个。因为 证书验证要求分发信任锚 独立地，指定信任锚的证书可以是 从链中省略，前提是支持的对等点已知 拥有任何遗漏的证书。

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

（客户端证书的另一个方向也是如此，但它们很少使用，而服务器证书几乎总是如此。）