ssl-certificate – 了解openssl s_client的输出

自从我们的电子邮件提供商更改了SSL证书后,基于单声道的POP3客户端拒绝连接到其安全POP服务器以下载电子邮件.其他客户没有问题;例如雷鸟和Outlook;大多数SSL检查站点都不能检查除this one之外的奇数端口.我一直在与两个提供商合作以试图查明问题,但最终两者都达到了死胡同,因为我不太了解SSL证书能够指导提供者了解故障所在.

在调查期间,我注意到以下两个命令的输出差异(为了便于阅读,我已从输出中删除了证书):

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

CONNECTED(00000003)
depth=2 /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
 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 CERTIFICATE-----
-----END CERTIFICATE-----
 1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2
   i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
   i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
---
Server certificate
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
---
No client certificate CA names sent
---
SSL handshake has read 3236 bytes and written 435 bytes
---
New, TLSv1/SSLv3, Cipher is RC4-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : RC4-SHA
    Session-ID: 745F84194498529B91B7D9194363CBBD23425446CF2BFF3BF5557E3C6606CA06
    Session-ID-ctx:
    Master-Key: DED1AE0A44609F9D6F54626F4370ED96436A561A59F64D66240A277066322DCD2CCB9A6D198C95F4D2B0C7E6781EECD2
    Key-Arg   : None
    Start Time: 1397678434
    Timeout   : 300 (sec)
    Verify return code: 20 (unable to get local issuer certificate)
---
+OK Gpop ready for requests from 69.3.61.10 c13mb42148040pdj
DONE

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

CONNECTED(00000003)
depth=2 /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
verify error:num=19:self signed certificate in certificate chain
verify return:0
---
Certificate chain
 0 s:/serialNumber=tG0GnsyAUkdX7DEo15ylNBjQJqAWZ/dD/OU=4159320284/OU=See www.rapidssl.com/resources/cps (c)14/OU=Domain Control Validated - RapidSSL(R)/CN=secure.emailsrvr.com
   i:/C=US/O=GeoTrust, Inc./CN=RapidSSL CA
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
 1 s:/C=US/O=GeoTrust, Inc./CN=RapidSSL CA
   i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
   i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
-----BEGIN CERTIFICATE-----
-----END CERTIFICATE-----
---
Server certificate
subject=/serialNumber=tG0GnsyAUkdX7DEo15ylNBjQJqAWZ/dD/OU=4159320284/OU=See www.rapidssl.com/resources/cps (c)14/OU=Domain Control Validated - RapidSSL(R)/CN=secure.emailsrvr.com
issuer=/C=US/O=GeoTrust, Inc./CN=RapidSSL CA
---
No client certificate CA names sent
---
SSL handshake has read 3876 bytes and written 319 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : DHE-RSA-AES256-SHA
    Session-ID: 3F4EE3992B46727BE2C7C3E76A9A6A8D64D66EE843CB1BB17A76AE2E030C7161
    Session-ID-ctx:
    Master-Key: 016209E50432EFE2359DB73AB527AF718152BFE6F88215A9CE40604E8FF2E2A3AC97A175F46DF737596866A8BC8E3F7F
    Key-Arg   : None
    Start Time: 1397678467
    Timeout   : 300 (sec)
    Verify return code: 19 (self signed certificate in certificate chain)
---
DONE

我一直试图了解这是否有意义,因为当提供-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 cert后,我也可以成功使用-CAfile选项.

然而,Fog Creek似乎认为问题在于证书,因为他们已经尝试将证书添加到mono的Trust商店但没有成功.我不同意他们,但(如上所述)虽然大多数SSL检查器要么不检查端口995或在尝试期间成功,我发现this page产生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充当一种“遗留”信任锚.

翻译自:https://serverfault.com/questions/589590/understanding-the-output-of-openssl-s-client

转载注明原文:ssl-certificate – 了解openssl s_client的输出