总结关于问题原因的评论并更详细地解释实际问题:
如果检查OpenSSL客户端的信任链,则会得到以下信息:
[0] 54:7D:B3:AC:BF:... /CN=*.s3.amazonaws.com [1] 5D:EB:8F:33:9E:... /CN=VeriSign Class 3 Secure Server CA - G3 [2] F4:A8:0A:0C:D1:... /CN=VeriSign Class 3 Public Primary Certification Authority - G5[OT] A1:DB:63:93:91:... /C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
第一个证书[0]是服务器发送的叶证书。以下证书[1]和[2]是服务器发送的链式证书。最后一个证书[OT]是受信任的根证书,该证书不是由服务器发送的,而是位于受信任CA的本地存储中。链中的每个证书都由下一个证书签名,最后一个证书[OT]受信任,因此信任链已完成。
如果您通过浏览器(例如,使用NSS库的Google Chrome)检查信任链,则会获得以下链:
[0] 54:7D:B3:AC:BF:... /CN=*.s3.amazonaws.com [1] 5D:EB:8F:33:9E:... /CN=VeriSign Class 3 Secure Server CA - G3[NT] 4E:B6:D5:78:49:... /CN=VeriSign Class 3 Public Primary Certification Authority - G5
服务器再次发送[0]和[1],但是[NT]是受信任的根证书。从对象的角度看,这就像连锁证书[2]一样,指纹表示证书是不同的。如果您仔细查看证书[2]和[NT],您会发现,证书内的公钥是相同的,因此[2]和[NT]均可用于验证[
1],因此可以用来建立信任链。
这意味着,尽管服务器在所有情况下都发送相同的证书链,但是有多种方法可以将链验证为受信任的根证书。如何完成此 *** 作取决于SSL库和已知的受信任根证书:
[0] (*.s3.amazonaws.com) | [1] (Verisign G3) -------------------------- | | /------------------ [2] (Verisign G5 F4:A8:0A:0C:D1...) | | | | certificates sent by server| .....|...............................................................|................ | locally trusted root certificates | | | [OT] Public Primary Certification Authority [NT] Verisign G5 4E:B6:D5:78:49 OpenSSL library Google Chrome (NSS library)
但是问题仍然是,为什么您的验证不成功。您所做的就是获取浏览器使用的受信任的根证书(Verisign G5
4E:B6:D5:78:49)和OpenSSL。但是在浏览器(NSS)和OpenSSL中的验证工作略有不同:
- NSS:根据服务器发送的证书建立信任链。当我们获得由任何本地信任的根证书签名的证书时,停止构建链。
- OpenSSL_根据服务器发送的证书构建信任链。完成此 *** 作后,检查我们是否有可信的根证书对链中的最新证书进行签名。
由于存在这种细微的差异,OpenSSL无法针对根证书[NT]来验证链[0],[1],[2],因为该证书不会对链[2]中的最新元素进行签名,而是对[1]进行签名。如果服务器只发送了[0],[1]链,则验证将成功。
这是一个众所周知的错误,并且存在补丁,并且希望通过引入该
X509_V_FLAG_TRUSTED_FIRST选项最终在OpenSSL
1.0.2中最终解决该问题。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)