openssl s_clientの出力を理解する

電子メールプロバイダーがSSL証明書を変更して以来、monoに基づくPOP3クライアントは、安全なPOPサーバーに接続して電子メールをダウンロードすることを拒否しています。他のクライアントには問題はありません。例：ThunderbirdおよびOutlook。また、これ以外の奇数ポートをチェックできるほとんどのSSLチェッカーサイトも同様です。私は両方のプロバイダーと協力して問題を特定しようとしましたが、SSL証明書については十分に知らないため、どちらのプロバイダーも障害の所在を理解することができないため、最終的に両方で行き詰まりました。

調査中、次の2つのコマンドの出力の違いに注意が向けられました（読みやすくするために、出力から証明書を削除しました）。

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 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
-----証明書の開始-----
-----証明書の終了-----
 1 s：/ C = US / O = Google Inc / CN = Google Internet Authority G2
   i：/ C = US / O = GeoTrust Inc./CN=GeoTrust Global CA
-----証明書の開始-----
-----証明書の終了-----
 2 s：/ C = US / O = GeoTrust Inc./CN=GeoTrust Global CA
   i：/ C = US / O = Equifax / OU = Equifax Secure Certificate Authority
-----証明書の開始-----
-----証明書の終了-----
---
サーバー証明書
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
    Session-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 Global CA
検証エラー：num = 19：証明書チェーン内の自己署名証明書
戻り値を確認する：0
---
証明書チェーン
 0 s：/serialNumber=tG0GnsyAUkdX7DEo15ylNBjQJqAWZ/dD/OU=4159320284/OU=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
-----証明書の開始-----
-----証明書の終了-----
 1 s：/ C = US / O = GeoTrust、Inc./CN=RapidSSL CA
   i：/ C = US / O = GeoTrust Inc./CN=GeoTrust Global CA
-----証明書の開始-----
-----証明書の終了-----
 2 s：/ 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 = Domain Control Validated-RapidSSL（R）/CN=secure.emailsrvr.comを参照
issuer = / 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
    Session-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
...

GeofileからCAfile証明書を直接-CAfileダウンロードした後、オプションを正常に使用することもできます。

それでも、フォグクリークは、証明書に問題があると考えているようです。なぜなら、Trust成功せずにモノのストアに証明書を追加しようとしたからです。私はそれらに同意しませんが、（上記のように）ほとんどのSSLチェッカーはポート995をチェックしないか、試行中に成功しますが、SSLエラー7を生成するこのページを見つけました。

出力を正しく解釈して、証明書に問題がないことを意味しますか？

答えは（このsecurity.SE投稿で説明されているように）チェーンに表示される2つのGeoTrustグローバルCA証明書は実際には同じ証明書ではなく、一方は他方から派生しているということです。

CAの相互署名のため！

GeoTrustグローバルCA証明書が最初に作成および署名されたとき、コンピューター/ブラウザー/アプリケーションは、トラストストアにそれを保持していませんでした。

（既存のレピュテーションとディストリビューションを持つ）別の CAがGeoTrustルートCA証明書に署名することにより、GeoTrustルートCA証明書がなくても、結果の証明書（「ブリッジ」証明書と呼ばれる）を2番目の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