1

(基本的に、HTTPS 接続のために特定のポートでリッスンしているリスナー) が開始されたSSLContextときにロードするリアクター パターンの実装があります。TransportListener

次に、同じinit()メソッドを再度呼び出します (リスナーのメソッドへのJMX呼び出しを介して)

sslContext.init(keyManagers, trustManagers, null);

トラスト ストアとの間で証明書を追加または削除したら。SSLContextリスナーのダウンタイムを避けるために、をリロードする必要があります。

これが私が現在直面している問題です。

リクエストがリスナーに届き、接続が確立されたとします。SSLContext応答がクライアントに返される前にオブジェクトをリロードすると、送信前にペイロードを暗号化する接続のSSLEngineオブジェクトのプロセスに影響しますか?wrap

注: 同じSSLContextオブジェクトがすべての SSLEngine に渡されていることを確認しました。SSLContext オブジェクトは、リスナーの開始時に他のいくつかのオブジェクトに渡されます。たとえば、この SSLContext オブジェクトを渡す必要がある接続プールがあります。したがって、新しい SSLContext オブジェクトを作成すると、接続プールである既存の接続が完全に切断されます。そのため、同じ SSLContext オブジェクトを使用しようとしています。

4

1 に答える 1

0

これを熟考する必要があります。接続が確立されている場合は、すでに証明書の交換が正常に行われているため、新しい証明書は必要ないためSSLContext、現在のセッションのキーを再生成するなどの部分的なハンドシェイクまで、新しいまたは再初期化する必要はありません。クライアント証明書を要求します。完全なハンドシェイク以外の目的で SSLContext を使用するべきではありません。

あなたがしなければならないことは、新しい証明書を必要とするすべての新しい接続に対して、新しい証明書の使用を開始することです。 定義上、既存の接続に対して何もする必要はありません。SSLContext

于 2016-09-02T01:54:07.673 に答える