☰

交叉签名 (Let's Encrypt) SSL 链验证

tag-icon • tag-icon ssl ssl-certificate lets-encrypt
交叉签名 (Let's Encrypt) SSL 链验证

注意：我花了大约 30 分钟来编写/制定这个问题，结果却变成了一场橡皮鸭会议。意识到我做错了什么，但无论如何还是发布它，因为它可能对其他人也有用。

就上下文而言，我每天都使用 SSL 证书，并认为自己对它们的工作原理有相当好的理解（至少我是这么认为的 :p）。我目前正在编写一个脚本来监控/测试我们托管的网站的 SSL 链问题，但我无法将链与根证书匹配。具体来说，是使用交叉签名证书的 Let's Encrypt 证书。如果我跟踪链，它会采用以下路径：

Subject: mywebsite.tld
Issuer: /C=US/O=Let's Encrypt/CN=E1

Subject: /C=US/O=Let's Encrypt/CN=E1
Serial: B3BDDFF8A7845BBCE903A04135B34A45
Issuer: /C=US/O=Internet Security Research Group/CN=ISRG Root X2

Subject: /C=US/O=Internet Security Research Group/CN=ISRG Root X2
Serial: 079E492886376FD40848C23FC631E463
Issuer: /C=US/O=Internet Security Research Group/CN=ISRG Root X1

Subject: /C=US/O=Internet Security Research Group/CN=ISRG Root X1
Serial: 4001772137D4E942B8EE76AA3C640AB7
Issuer: /O=Digital Signature Trust Co./CN=DST Root CA X3

因此与 LE 网站上记录的预期路径非常相似。

但是，我的系统（使用 mozilla ca 证书https://wiki.mozilla.org/CA/Included_Certificates) 不信任 DST Root CA X3。但它信任 ISRG X2 和 ISRG X1 证书。但该存储中的证书不是上述链中使用的交叉签名证书，而是自签名证书。

Subject: /C=US, O=Internet Security Research Group, CN=ISRG Root X2
Serial: 41D29DD172EAEEA780C12C6CE92F8752
Issuer: /C=US, O=Internet Security Research Group, CN=ISRG Root X2

Subject: /C=US/O=Internet Security Research Group/CN=ISRG Root X1
Serial: 8210CFB0D240E3594463E0BB63828B00
Issuer: /C=US/O=Internet Security Research Group/CN=ISRG Root X1

那么，如果不是通过遵循证书链并检查该证书是否与受信任的证书库匹配，我的计算机/浏览器实际上如何进行匹配？按照我的逻辑，网站证书链中引用的 E1、X2 和 X1 证书是指向不受信任的根证书的中间证书，而不是根证书本身。那么我没看到什么呢？

答案1

因此，为了回答我自己的问题，证书和受信任的根证书之间的匹配不是在证书级别完成的，而是在用于创建（而不是签署）证书的密钥上完成的。

在这种情况下，交叉签名证书和自签名ISRG Root X2证书都是从具有主题密钥标识符的相同密钥创建的7C:42:96:AE:DE:4B:48:3B:FA:92:F8:9E:8C:CF:6D:8B:A9:72:37:95。Let's Encrypt E1证书不指向特定的颁发者证书，而是指向具有该特定名称且由特定密钥颁发的证书。系统将搜索受信任的存储区以查看其中是否包含具有该名称和该密钥的证书。由于自签名证书具有相同的名称，并且是使用相同的密钥创建的，因此可以将其链接到 E1 证书，从而建立指向受信任的根证书的链接。

如果无法建立信任，则该过程将继续使用服务器发送的链，并对 X1 证书进行相同的检查。此过程重复进行，直到在受信任的存储中找到匹配的证书，或者直到链中没有其他证书（此时验证失败）

相关内容