共有SSLContextオブジェクトのinit（）を再度呼び出すときのSSLEngineへの影響

Question

TransportListener（基本的にHTTPS接続用に特定のポートをリスンするリスナー）が起動するときに、SSLContextをロードするリアクタパターンの実装があります。 。私は信頼ストアから/に証明書を追加または削除したら

は、その後、私は（リスナーのメソッドにJMXコールを介して）

sslContext.init(keyManagers, trustManagers, null); 

再び同じinit()メソッドを呼び出します。リスナーのダウンタイムを避けるために、SSLContextをリロードする必要があります。

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

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

注：リスナーが起動されたとき、私は同じSSLContextオブジェクトはすべてSSLEngines.The SSLContextオブジェクトに渡されていることを検証していますが、いくつかの他のオブジェクトに渡されます。たとえば、このSSLContextオブジェクトを渡す必要がある接続プールがあります。したがって、新しいSSLContextオブジェクトを作成すると、接続プールが完全に破棄されます。そのため、私は同じSSLContextオブジェクトを使用しようとしています。

Answer 1

あなたはこれを考える必要があります。接続が確立されている場合は、既に証明書交換が行われているため、新しい証明書は必要ありません。したがって、部分ハンドシェイクまでの新規または再初期化の必要はありません。現在のセッションのキーを再入力するか、クライアント証明書を要求します。 SSLContextは完全なハンドシェイクが不足している場合には使用しないでください。あなたがする必要がどのような

は、新しい証明書を必要としているすべての新しい接続用の新しいSSLContextを使用し始めています。既存の接続には定義上何もする必要はありません。