7

クライアントにはルート証明書しかなく、サーバーにはルート証明書と中間証明書の両方がある場合、SSL を使用してサイトに接続できますか?

ルートを含む TrustManager で HttpUrlConnection を使用して接続しようとしていますが、通常のハンドシェイク エラーが発生します。

javax.net.ssl.SSLHandshakeException:
  sun.security.validator.ValidatorException:
  Certificate chaining error
    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
    at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:379)

一般的な解決策は中間証明書をインストールすることであることはわかっていますが、ベンダー X の新しい中間証明書を取得するという絶え間ない一時的なことは避けたいと思います。

すべてを受け入れる TrustManager の使用に慣れていますが、それはオプションではありません。

4

4 に答える 4

16

クライアントにはルート証明書しかなく、サーバーにはルート証明書と中間証明書の両方がある場合、SSL を使用してサイトに接続できますか?

これは可能であるだけでなく、実際には TLS が機能する通常の方法です。

  1. TLS クライアントにはルート証明書しかありません。Java (少なくとも Oracle JVM lib/security/cacerts) は、JRE インストール ディレクトリからそれらを読み取ります。ブラウザーには、独自の内部リストがあるか、オペレーティング システムによって提供されるリストが使用されます。
  2. クライアントが TLS 接続を開始すると、サーバーは独自の証明書を中間証明書 (使用する場合) と共に送り返すことになっています。このリストは証明書チェーンと呼ばれます。現在のバージョンは 1.2 です。TLS のこれは、RFC 5246 のセクション 7.4.2 で指定されています (以下の引用を参照してください)。
  3. クライアントはこれらの証明書を受け取り、サーバー証明書から既知のルート証明書の 1 つまでの署名を検証します。これは、Certification Path Buildingと呼ばれ、 RFC 4158で説明されています。
  4. クライアントが有効な証明書パスを構築できる場合は、接続のセットアップを続行します。それ以外の場合は、エラー メッセージが表示されて中止されます。これは、恐ろしい「この接続は信頼されていません」というエラーのようなものです。

一般的な解決策は、中間証明書をインストールすることであることを知っています

いいえ、実際にはそうではありません。上記で説明したように、サーバーはすべての中間証明書を自動的に送信する必要があります。

でも：

サーバーでよくある構成エラーの 1 つは、すべての中間証明書をサーバーにインストールしないことです。その場合、サーバーは接続のセットアップ中に不完全な証明書チェーンを送信します。その場合、クライアントは有効な証明書パスを構築できず、接続を中止します。

合併症によっては、この問題の診断が難しくなることがあります。

  • 一部のクライアント (特にブラウザー) は、不足している中間証明書のコピーがキャッシュされているため、正常に接続できる場合があります。
  • ほとんどのクライアントは、欠落している中間証明書 (サーバーによって送信されたチェーン内)、欠落しているルート証明書 (独自のリスト内)、および自己署名証明書を区別しないか、または区別できないため、自分で何を把握する必要があります。問題は実際にあります。

これらの問題を診断するための便利なツール:

  • OpenSSL のコマンド ライン クライアントは、サーバーが送信する証明書チェーンを表示できます。openssl s_client -showcerts -connect google.com:443
  • Qualys のSSL サーバー テストでは、証明書チェーンと検証エラーが一覧表示されます。

RFC 5246 のセクション 7.4.2からの関連する引用:

7.4.2. サーバー証明書

このメッセージが送信されるタイミング:

合意された鍵交換方法が認証に証明書を使用するときはいつでも、サーバーは証明書メッセージを送信する必要があります (これには、DH_anon を除く、このドキュメントで定義されているすべての鍵交換方法が含まれます)。このメッセージは、常に ServerHello メッセージの直後に表示されます。

このメッセージの意味:

このメッセージは、サーバーの証明書チェーンをクライアントに伝えます。

[...]

このメッセージの構造:

[...]

証明書リスト

これは証明書のシーケンス (チェーン) です。送信者の証明書は、リストの最初に来る必要があります。次の各証明書は、その前の証明書を直接認証する必要があります。証明書の検証では、ルート キーを個別に配布する必要があるため、ルート認証局を指定する自己署名証明書は、いずれにしても検証するためにリモート エンドがすでに所有している必要があるという前提の下で、チェーンから省略される場合があります。

于 2015-04-10T09:22:58.877 に答える
-2

サーバーに、ルートCA（Verisignなど）によって署名されたsub-ca-Aによって署名された証明書がある場合、サーバーは、サーバーの証明書を検証できるように、サーバーhelloの一部としてすべての証明書を送信します。

あなたの場合、トラストストアにはルートCAしかありません。

その結果、sub-ca証明書が欠落しているため、信頼の検証チェーンを確立することはできません。
それは不可能であるだけでなく、それができるのは間違っている/安全ではないでしょう。ですから、あなたがしていることは、適切な道から外れていることです。

したがって、2つのオプションしかありません。
サーバーの実際の証明書を信頼できるものとしてトラストストアに配置します。
チェーン全体をトラストストアに配置します。つまり、ルートとともに中間CA証明書を配置します。

あなたの懸念は何ですか？中間証明書の有効期限？

于 2012-04-12T18:11:51.380 に答える