私たちは問題に直面しており、ここが適切な場所であると確信しています。ロード バランサー (cisco) があり、さまざまな理由から、ロード バランサー (サーバー) 側の SSL 構成は "SSLv3" プロトコル バージョンを使用するように設定されています。同じ設定を行った後、CHROME ブラウザーでロード バランサーにアクセスするとページにアクセスできますが、セキュリティ アイコンをクリックすると以下のメッセージが表示されます。
「接続はssl 3.0を使用して再試行する必要がありました」-wiresharkを使用してパケットキャプチャを調べたところ、ブラウザーがTLSv1を試行し、サーバーから「protocol_version」という「致命的なアラート」を受け取り、すぐにブラウザーがSSLv3バージョンを試行して終了することがわかりましたハンドシェーク。したがって、ブラウザはこれをクライアントとしてネゴシエートできます。
ただし、Eclipse からスタンドアロン Java (1.6 と 1.7 を使用してみました) クライアントをセットアップし、サーバーに接続しようとすると、以下の例外が発生します。
: 致命的なアラートを受信しました: protocol_version javax.net.ssl.SSLException: 致命的なアラートを受信しました: protocol_version
さまざまなドキュメントに従って、私が持っている2つのオプションを見ました
https.protocol システム プロパティを SSLv3 に設定します。[これは私たちにとってはうまくいきますが、問題は、アウトバウンド SSL 呼び出しにグローバルに影響することです。SSLv3 で動作しない別のサーバーへの別のアウトバウンド SSL 呼び出しがあります]
setEnabledprotocols() - これも同様に機能しますが、ソケットに直接アクセスできない場合があります (サードパーティを使用してスタブを生成し、スタブが低レベルの接続を処理するため、そのソケットにアクセスできない場合があります)。
しかし、私の実際の質問は、デフォルトで TLSv1/SSLv3 と SSLv2Hello (私が信じている形式) が Java で有効になっている場合、クロム ブラウザーがネゴシエートできるように JSSE 実装がネゴシエートできないのはなぜですか。これは期待されていますか？ブラウザがそれを行っている場合、それはSSL RFCの一部であるべきだと思います。そうであれば、この「ネゴシエーション」と同じ機能がJava自体によって提供されるべきですよね?
私はこのhttp://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/6-b14/sun/security/ssl/SSLSocketImpl.javaを調べましたが、どの部分も見つけることができませんでしたハンドシェイク中のこのネゴシエーションのために。
サーバー側（ロードバランサー）からの問題の可能性はありますか？サーバーが致命的なアラートを送信していることがわかりますが、cisco であるため、ssl の実装は完璧である必要があり、それは想定されていることです。私が間違っている？
この問題は、Java 1.6 と 1.7 の両方で発生します。回答にさらに情報が必要な場合はお知らせください。喜んでお手伝いさせていただきます。