openssl s_clientの出力について
メールプロバイダーがSSL証明書を変更して以来、monoベースのPOP3クライアントは、安全なPOPサーバーに接続してメールをダウンロードすることを拒否しています。他のクライアントには問題はありません。例えばThunderbirdとOutlook; this one を除いて、奇数のポートをチェックできるほとんどのSSLチェッカーサイトも同様です。私は問題を特定するために両方のプロバイダーと協力してきましたが、SSL証明書について十分に知らないので、どちらのプロバイダーも障害がどこにあるのかを理解することができません。
調査中、次の2つのコマンドの出力の違いに注意が向けられました（読みやすくするために出力から証明書を削除しました）。
echo "" | openssl s_client -showcerts -connect pop.gmail.com:995
CONNECTED（00000003） depth = 2/C = US/O = GeoTrust Inc./CN=GeoTrust Global CA verifyerror： num = 20：ローカル発行者証明書を取得できません verify return：0 --- Certificate chain 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 ----- 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 ----- --- サーバー証明書 subject =/C = US/ST = California/L = Mountain View/O = Google Inc/CN = pop.gmail.com issuer =/C = US/O = Google Inc/CN = Google Int ernet Authority G2 --- 送信されたクライアント証明書CA名なし --- SSLハンドシェイクは3236バイトを読み取り、435バイトを書き込みました--- New、TLSv1/SSLv3、Cipher is RC4-SHA Server public key is 2048 bit Secure Renegotiation IS supported 圧縮：なし 拡張：なし SSL-Session： プロトコル：TLSv1 暗号：RC4-SHA セッションID： 745F84194498529B91B7D9194363CBBD23425446CF2BFF3BF5557E3C6606CA06 セッションID-CTX： マスターキー：DED1AE0A44609F9D6F54626F4370ED96436A561A59F64D66240A277066322DCD2CCB9A6D198C95F4D2B0C7E6781EECD2 キーのArg：なし 開始時間：1397678434 タイムアウト：300（ sec） 戻りコードを確認します：20（ローカル発行者証明書を取得できません） --- + OK 69.3.61.10からの要求に対してGpopの準備ができています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 verifyerror： num = 19：証明書チェーン内の自己署名証明書 verify return：0 --- Certificate chain 0秒：/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 ----- 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 ----- --- サーバー証明書 subject =/serialNumber = tG0GnsyAUkdX7DEo15ylNBjQJ qAWZ/dD/OU = 4159320284/OU = www.rapidssl.com/resources/cpsを参照（c）14/OU =検証済みドメイン制御-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ビット セキュア再ネゴシエーションISサポート 圧縮：NONE 拡張：NONE SSL-Session： プロトコル：TLSv1 [。 。____]暗号：DHE-RSA-AES256-SHA [.____]セッションID：3F4EE3992B46727BE2C7C3E76A9A6A8D64D66EE843CB1BB17A76AE2E030C7161 [.____]セッションID-CTX：[.____]マスターキー：。016209E50432EFE2359DB73AB527AF718152BFE6F88215A9CE40604E8FF2E2A3AC97A175F46DF737596866A8BC8E3F7F [.____]キー - 。引数：なし 開始時間：1397678467 タイムアウト：300（秒） 戻りコードを確認：19（certiの自己署名証明書） ficate 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
...
CAfile cert をGeoTrustから直接ダウンロードした後、-CAfileオプションを正常に使用することもできます。
それにもかかわらず、フォグクリークは問題が証明書にあると考えているようです。なぜなら、彼らは証明書をモノのTrustストアに追加しようとして成功しなかったからです。私はそれらに同意しませんが、（上記のように）ほとんどのSSLチェッカーはポート995をチェックしないか、試行中に成功しますが、SSLエラー7を生成する このページ が見つかりました。
出力を正しく解釈して、証明書に問題がないことを意味しますか？
答え（この security.SEの投稿 で説明されています）は、チェーンに表示される2つのGeoTrust Global CA証明書です実際には同じ証明書ではありません、一方は他方から派生しています。
CAクロス署名のため！
GeoTrust Global CA証明書が最初に作成されて署名されたとき、コンピューター/ブラウザー/アプリケーションはそれらをトラストストアに持っていなかったでしょう。
別のCA（既存のレピュテーションと配布を使用）がGeoTrustルートCA証明書に署名することにより、結果の証明書（「ブリッジ」証明書と呼ばれる）を検証できるようになりました。 2番目のCAによって、GeoTrustルートCA証明書がクライアントによって明示的に信頼される必要はありません。
GoogleがGeoTrustルートCA証明書のクロス署名バージョンを提示すると、オリジナルを信頼しないクライアントは、Equifax CA証明書を使用してGeoTrustを検証できます。そのため、Equifaxは一種の「レガシー」トラストアンカーとして機能します。
pop.gmail.comのsslチェックを有効にすると、fetchmailで同様の問題が発生しました。
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
証明書を生成して設定するとき、適切なパスや証明書名などを示すために、openssl.cnfファイルも更新する必要があります（Debian-/etc/ssl/openssl.cnf）。次に、コマンドを実行して、-CApathオプションなしでそれらをチェックできます。
したがって、この場合、リモートホストも証明書を適切にチェックできます。
以下は、適切なopenssl.cnfセクションです。
####################################################################
[ ca ]
default_ca = CA_default # The default ca section
####################################################################
[ CA_default ]
dir = /etc/ssl