了解openssl s_client的输出

自从我们的电子邮件提供商更改其SSL证书以来，基于mono的POP3客户端就拒绝连接到其安全的POP服务器以下载电子邮件。其他客户没有问题；例如Thunderbird和Outlook；无论这是否是能够检查单端口，除了大多数SSL检查点这一个。我一直在与两家提供商合作，试图找出问题所在，但最终两家都陷入了僵局，因为我对SSL证书的了解不足，无法指导任何一家提供商了解问题所在。

在调查过程中，我注意到了以下两个命令的输出差异（出于可读性考虑，我从输出中删除了证书）：

echo "" | openssl s_client -showcerts -connect pop.gmail.com:995

已连接（00000003）
depth = 2 / C = US / O = GeoTrust Inc./CN=GeoTrust全球CA
验证错误：num = 20：无法获取本地颁发者证书
验证返回：0
---
证书链
 0 s：/ C = US / ST = California / L = Mountain View / O = Google Inc / CN = pop.gmail.com
   i：/ C = US / O = Google Inc / CN = Google Internet Authority G2
----- BEGIN证书-----
-----结束证书-----
 1 s：/ C = US / O = Google Inc / CN = Google Internet Authority G2
   i：/ C = US / O = GeoTrust Inc./CN=GeoTrust全球CA
----- BEGIN证书-----
-----结束证书-----
 2秒：/ C = US / O = GeoTrust Inc./CN=GeoTrust全球CA
   i：/ C = US / O = Equifax / OU = Equifax安全证书颁发机构
----- BEGIN证书-----
-----结束证书-----
---
服务器证书
subject = / C = US / ST = California / L = Mountain View / O = Google Inc / CN = pop.gmail.com
issuer = / C = US / O = Google Inc / CN = Google Internet Authority G2
---
未发送客户端证书CA名称
---
SSL握手已读取3236字节，已写入435字节
---
全新TLSv1 / SSLv3，密码为RC4-SHA
服务器公钥为2048位
支持安全重新协商
压缩：无
扩展：无
SSL会话：
    通讯协定：TLSv1
    密码：RC4-SHA
    会话ID：745F84194498529B91B7D9194363CBBD23425446CF2BFF3BF5557E3C6606CA06
    会话ID-ctx：
    万能钥匙：DED1AE0A44609F9D6F54626F4370ED96436A561A59F64D66240A277066322DCD2CCB9A6D198C95F4D2B0C7E6781EECD2
    Key-Arg：无
    开始时间：1397678434
    超时：300（秒）
    验证返回码：20（无法获取本地发行者证书）
---
+ OK Gpop已准备好接受来自69.3.61.10 c13mb42148040pdj的请求
完成

echo "" | openssl s_client -showcerts -connect secure.emailsrvr.com:995

已连接（00000003）
depth = 2 / C = US / O = GeoTrust Inc./CN=GeoTrust全球CA
验证错误：num = 19：证书链中的自签名证书
验证返回：0
---
证书链
 0 s：/ serialNumber = tG0GnsyAUkdX7DEo15ylNBjQJqAWZ / dD / OU = 4159320284 / OU =请参阅www.rapidssl.com/resources/cps（c）14 / OU =已验证域控制-RapidSSL（R）/CN=secure.emailsrvr.com
   i：/ C = US / O = GeoTrust，Inc./CN=RapidSSL CA
----- BEGIN证书-----
-----结束证书-----
 1秒：/ C = US / O = GeoTrust，Inc./CN=RapidSSL CA
   i：/ C = US / O = GeoTrust Inc./CN=GeoTrust全球CA
----- BEGIN证书-----
-----结束证书-----
 2秒：/ C = US / O = GeoTrust Inc./CN=GeoTrust全球CA
   i：/ C = US / O = GeoTrust Inc./CN=GeoTrust全球CA
----- BEGIN证书-----
-----结束证书-----
---
服务器证书
subject = / serialNumber = tG0GnsyAUkdX7DEo15ylNBjQJqAWZ / dD / OU = 4159320284 / OU =请参阅www.rapidssl.com/resources/cps（c）14 / OU =已验证域控制-RapidSSL（R）/CN=secure.emailsrvr.com
发行者= / C = US / O = GeoTrust，Inc./CN=RapidSSL CA
---
未发送客户端证书CA名称
---
SSL握手已读取3876字节，已写入319字节
---
新型TLSv1 / SSLv3，密码为DHE-RSA-AES256-SHA
服务器公钥为2048位
支持安全重新协商
压缩：无
扩展：无
SSL会话：
    通讯协定：TLSv1
    密码：DHE-RSA-AES256-SHA
    会话ID：3F4EE3992B46727BE2C7C3E76A9A6A8D64D66EE843CB1BB17A76AE2E030C7161
    会话ID-ctx：
    万能钥匙：016209E50432EFE2359DB73AB527AF718152BFE6F88215A9CE40604E8FF2E2A3AC97A175F46DF737596866A8BC8E3F7F
    Key-Arg：无
    开始时间：1397678467
    超时：300（秒）
    验证返回码：19（证书链中的自签名证书）
---
完成

我一直试图了解这是否有意义，因为-CApath提供该选项时，这些命令不会产生任何错误：

openssl s_client -CApath /etc/ssl/certs -showcerts -connect secure.emailsrvr.com:995

CONNECTED(00000003)
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
verify return:1
depth=1 C = US, O = "GeoTrust, Inc.", CN = RapidSSL CA
verify return:1
depth=0 serialNumber = tG0GnsyAUkdX7DEo15ylNBjQJqAWZ/dD, OU = 4159320284, OU = See www.rapidssl.com/resources/cps (c)14, OU = Domain Control Validated - RapidSSL(R), CN = secure.emailsrvr.com
verify return:1
...

openssl s_client -CApath /etc/ssl/certs -showcerts -connect pop.gmail.com:995

CONNECTED(00000003)
depth=3 C = US, O = Equifax, OU = Equifax Secure Certificate Authority
verify return:1
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
verify return:1
depth=1 C = US, O = Google Inc, CN = Google Internet Authority G2
verify return:1
depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN = pop.gmail.com
verify return:1
...

直接从GeoTrust -CAfile下载CAfile证书后，我也可以成功使用该选项。

但是，Fog Creek似乎认为证书存在问题，因为他们尝试将证书添加到mono的Trust商店中没有成功。我不同意它们，但是（如上所述），尽管大多数SSL检查器要么不检查端口995，要么在尝试期间未成功，但我发现此页面产生SSL错误7。

我是否正确解释输出以表示证书没有问题？

答案（如本security.SE post中所述）是，您在链中看到的两个GeoTrust Global CA证书实际上不是同一证书，一个是从另一个证书派生的。

由于CA交叉签名！

首次创建并签署GeoTrust Global CA证书时，没有计算机/浏览器/应用程序在其信任库中拥有该证书。

通过让另一个 CA（具有预先存在的声誉和分发）签署GeoTrust根CA证书，现在可以由第二个CA验证生成的证书（称为“桥接”证书），而无需具有GeoTrust根CA证书被客户明确信任。

当Google提供GeoTrust根CA证书的交叉签名版本时，不信任原始证书的客户端可以使用Equifax CA证书来验证GeoTrust-因此，Equifax充当一种“旧式”信任锚。

当我为启用ssl检查时，fetchmail也有类似的问题pop.gmail.com。

我下载了Equifax pem文件，但它不能按原样工作，必须运行c_rehash ssl/certs该程序才能创建具有哈希值的符号链接，然后它才可以工作。

另外，也可以通过运行...来了解哈希值。

openssl x509 -in Equifax_Secure_Certificate_Authority.pem -fingerprint -subject -issuer -serial -hash -noout | sed  -n /^[0-9]/p

https://www.geotrust.com/resources/root_certificates/certificates/Equifax_Secure_Certificate_Authority.pem

在生成和配置证书时，还应该更新openssl.cnf文件（Debian-/etc/ssl/openssl.cnf），以指示正确的路径，证书名称等，然后您可以运行命令并检查它们，而无需-CApath选择任何选项。

因此，在这种情况下，远程主机也可以正确检查您的证书。

这是适当的openssl.cnf部分：

####################################################################
[ ca ]

default_ca  = CA_default        # The default ca section

####################################################################
[ CA_default ]

dir     = /etc/ssl