了解 openssl s_client 的输出

Question

自从我们的电子邮件提供商更改了他们的 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 Global CA
验证错误：num=20：无法获得本地颁发者证书
验证返回：0
---
证书链
 0 秒：/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
-----开始认证-----
-----结束证书-----
 1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2
   i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
-----开始认证-----
-----结束证书-----
 2 秒：/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
   i:/C=US/O=Equifax/OU=Equifax 安全证书颁发机构
-----开始认证-----
-----结束证书-----
---
服务器证书
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
    键参数：无
    开始时间：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 Global CA
验证错误：num=19：证书链中的自签名证书
验证返回：0
---
证书链
 0 s:/serialNumber=tG0GnsyAUkdX7DEo15ylNBjQJqAWZ/dD/OU=4159320284/OU=参见 www.rapidssl.com/resources/cps (c)14/OU=域控制验证 - RapidSSL(R)/CNrv=secure.commailsr
   i:/C=US/O=GeoTrust, Inc./CN=RapidSSL CA
-----开始认证-----
-----结束证书-----
 1 秒：/C=US/O=GeoTrust, Inc./CN=RapidSSL CA
   i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
-----开始认证-----
-----结束证书-----
 2 秒：/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
   i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
-----开始认证-----
-----结束证书-----
---
服务器证书
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
    键参数：无
    开始时间：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。

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

Answer 1

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

因为 CA 交叉签名！

首次创建和签署 GeoTrust Global CA 证书时，没有计算机/浏览器/应用程序将其保存在其信任存储中。

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

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

Answer 2

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

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

这是适当的openssl.cnf部分：

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

default_ca  = CA_default        # The default ca section

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

dir     = /etc/ssl