Question

我制作了一个程序，可以连接到网站（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

我的问题是：

这种情况正常吗？
Web服务器（这次是adblockplus）正在制作证书路径吗？
如何确定有效的证书路径？

欢迎任何评论。谢谢

Answer 1

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

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版本，但最终实体证书除外      必须是第一位。

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

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

1 个答案: