web-dev-qa-db-ja.com

SSLハンドシェイクは、2つのCA署名証明書と1つの自己署名証明書を含むベリサインチェーン証明書で失敗します

問題が発生したため、デバッグしようとしています。 Verisign証明書を購入しました。使用する場合：

_openssl> s_client -connect myweb.com:443 -showcerts
_

SSLハンドシェイクは決して完了せず、最後にエラーが表示されます。

_Verify return code: 19 (self signed certificate in certificate chain)
_

3つの_---BEGIN/END CERTIFICATE---_タグが表示されます。チェーン内の2つの証明書はVerisign署名されていますが、1つは自己署名されています。

  1. この自己署名証明書がCA署名証明書にどのように表示されるかを誰かが説明できますか？

  2. このエラーは19 (self signed certificate in certificate chain)良性ですか？そうでない場合、何が原因ですか？

  3. クライアントは信頼できるストアにCA証明書を持っていますが、自己署名証明書には何もありません。それが問題を引き起こしていると思いますか？はいの場合、どうすればよいですか：

    1. チェーン内の2つのCA署名証明書のみを残して、チェーン証明書から自己署名証明書を削除するにはどうすればよいですか？
    2. この自己署名証明書をクライアントの信頼できるストアに追加しますか？
sslopensslhandshake
40
curiousone

CAによって発行されるルート証明書は、自己署名証明書です（中間CA証明書の発行に使用される場合があります）。多くのブラウザやOSトラストアンカーにデフォルトでインポートされていることを除いて、彼らはあまり特別なものではありません。

ブラウザと一部のツールは、opensslコマンドが認識していない限り、デフォルトで場所で信頼できるCA証明書（一部は自己署名可能）を検索するように構成されています。

そのため、エンドエンティティ証明書（サーバーの証明書）からルートCA証明書（おそらく中間CA証明書を含む）までの証明書の完全なチェーンを提示するサーバーには、チェーン内に自己署名証明書があります：ルートCA 。

openssl s_client -connect myweb.com:443 -showcertsには、VerisignのルートCA証明書を信頼する特別な理由はなく、自己署名されているため、「証明書チェーン内の自己署名証明書」が得られます。

システムに、デフォルトで信頼されている証明書のバンドルがある場所がある場合（/etc/pki/tls/certs RedHat/Fedoraおよび/etc/ssl/certs Ubuntu/Debianの場合、OpenSSLを設定して、これらをトラストアンカーとして使用できます。たとえば、次のようになります。

openssl s_client -connect myweb.com:443 -showcerts -CApath /etc/ssl/certs
72
Bruno

中間証明書が欠落しているようです。 2006年4月現在、VeriSignによって発行されたすべてのSSL証明書には、中間CA証明書のインストールが必要です。

サーバーに証明書チェーン全体がロードされていない可能性があります。一部の企業では、コンピューターで追加の証明書をダウンロードできないため、SSLハンドシェイクの完了に失敗します。

中間チェーンに関する情報を次に示します。
https://knowledge.verisign.com/support/ssl-certificates-support/index?page=content&id=AR657
https://knowledge.verisign.com/support/ssl-certificates-support/index?page=content&id=AD146

中間CA証明書

8
Brettski

サーバーについては、RFC-5246「トランスポート層セキュリティ（TLS）プロトコルバージョン1.2」ドキュメントから抽出されたルート証明書をクライアントに配信するかどうかを指定できます。

証明書リスト
これは証明書のシーケンス（チェーン）です。送信者の証明書はリストの最初に来なければなりません。次の各証明書は、その前の証明書を直接認証する必要があります。証明書の検証にはルートキーを個別に配布する必要があるため、ルート認証局を指定する自己署名証明書[〜＃〜] may [〜＃〜]は、
リモートエンドは、どのような場合でも検証するためにすでにそれを所有している必要があると仮定しています。

RFC-2119「Best Current Practice」から抽出された用語「MAY」については次のように述べています：

5.MAY
この単語、または形容詞「オプション」は、アイテムが本当にオプションであることを意味します。あるベンダーは、アイテムを含めることを選択できます。
特定の市場ではそれが必要であるか、ベンダーが
製品を強化する一方で、別のベンダーは同じアイテムを省略できます。
特定のオプションを含まない実装は
別の実装と相互運用する準備
オプションを含めますが、おそらく機能が低下します。同じように、特定のオプションを含む実装
別の実装と相互運用する準備をする必要があります
オプションは含まれません（もちろん、機能の場合を除き、
オプションが提供されます。）

結論として、ルートは、ハンドシェイクでサーバーによって配信された証明書パスにある可能性があります。

実用化。
ナビゲーターのユーザー用語ではなく、インターネットアクセスが制限されている軍事ゾーンのサーバーにある転送ツールについて考えてください。
転送時にクライアントの役割を果たしているサーバーは、サーバーからすべての証明書パスを受け取ります。
チェーン内のすべての証明書をチェックして、ルートが含まれていることを確認してください。
これを確認する唯一の方法は、転送時に証明書パスにルートを含めることです。これは、以前にそれらの「信頼できる」ローカルコピーとして宣言されたものと照合されます。

4
garcia

VeriSignのSSL証明書インストールチェッカーへのリンクは次のとおりです。 https://knowledge.verisign.com/support/ssl-certificates-support/index?page=content&id=AR11

URLを入力し、[このWebサーバーをテスト]をクリックすると、中間認証局に問題があるかどうかが通知されます。

3
Aaron

「Verify return code: 19 (self signed certificate in certificate chain)」が表示された場合、サーバーが実際に自己署名証明書を使用しようとしている（クライアントがこれを確認できない）か、OpenSSLがアクセスできない必要なルートですが、サーバーはそれ自体を提供しようとしています（無意味なので、クライアントはサーバーを信頼して、サーバー自身の証明書に対応するルートを提供することはできません）。

繰り返しますが、-showcertsを追加すると、どちらを診断するのに役立ちます。

1
Dev