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

Question

我制作了一个程序，可以连接到website（tls）并将证书链保存到文件中。

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

此证书链之一是由Sectigo（ex Comodo）CA发行的。

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

$ 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. Web服务器（这次是adblockplus）是否正在制作证书路径？
3. 如何确定有效的证书路径？

欢迎任何意见。 谢谢

Answer 1

TLS-was-SSL服务器应该在握手中以正确的顺序发送证书链，但是有些不能，并且通过匹配issuer = subject名称，大多数客户端（包括OpenSSL）仍然可以正确处理证书链，只要叶子（最终实体）证书是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，重点是：

...发件人的证书必须位于列表中的第一个CertificateEntry中。 随后的每个证书都应直接对紧接其之前的证书进行认证。 因为证书的验证要求信任锚的分配是独立的，所以可以从链中省略指定信任锚的证书，前提是已知支持的对等方拥有任何省略的证书。

注意：在TLS 1.3之前，“ certificate_list”命令要求每个证书对紧接其之前的证书进行认证； 但是，某些实现允许一些灵活性。 服务器有时会出于过渡的目的同时发送当前和不建议使用的中间设备，而其他服务器的配置却很不正确，但是仍然可以正确验证这些情况。 为了获得最大的兼容性，所有实现都应准备处理来自任何TLS版本的潜在无关证书和任意顺序，但必须首先使用最终实体证书。

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