再次调用共享 SSLContext 对象的 init() 时对 SSLEngine 的影响答案

【问题标题】：Effect to a SSLEngine when calling init() of a shared SSLContext object again再次调用共享 SSLContext 对象的 init() 时对 SSLEngine 的影响
【发布时间】：2017-01-09 13:25:56
【问题描述】：

我有一个反应器模式的实现，当TransportListener（基本上是在给定端口上侦听HTTPS连接的侦听器。）启动时，我加载SSLContext。

然后我再次调用相同的 init() 方法（通过 JMX 调用侦听器的方法）

sslContext.init(keyManagers, trustManagers, null);

一旦我在信任存储中添加或删除证书。我必须重新加载 SSLContext 以避免监听器出现任何停机时间。

所以这是我目前面临的问题。

假设一个请求到达监听器并建立了一个连接。如果我在响应返回给客户端之前重新加载SSLContext 对象，这是否会影响连接的SSLEngine 对象的wrap 进程，该进程在发送前对有效负载进行加密？

注意：我已经验证了相同的 SSLContext 对象正在传递给所有 SSLEngines。当侦听器启动时，SSLContext 对象被传递给其他几个对象。例如，我有一个连接池，我必须将此 SSLContext 对象传递到该连接池。因此创建一个新的 SSLContext 对象将完全打破现有的连接是连接池。这就是为什么我尝试使用相同的 SSLContext 对象。

【问题讨论】：

没有什么能阻止你自己测试这个之前决定这是你“必须”做的。每当您加载新证书时，没有什么可以阻止您开始使用 new SSLContext：这也将避免侦听器中的任何停机时间。您根本不能将相同的SSLSession 传递给任何SSLEngines，更不用说传递给多个SSLEngines。你的意思是SSLContext？
...您可以在不设置新上下文的情况下修改信任库。
我已经对所有其他用例进行了测试。但是我无法重现上面提到的场景（在发送响应之前但在收到请求之后修改 sslcontext）。 @eckes我修改信任库没有问题。我需要的是在运行时重新加载信任库而不重新启动Listener。
@EJP 我不太明白你在说什么。我的意思是，当Listener 启动时，SSLContext 对象被传递给其他几个对象。例如，我有一个连接池，我必须将这个 SSLContext 对象传递到该连接池。因此创建一个新的SSLContext 对象将完全中断流程。这就是为什么我尝试使用相同的 SSLContext 对象。
您需要阅读自己的帖子。你实际上说是，我引用的是，'同一个SSLSession对象被传递给所有SSLEngines'。请说清楚。并且“因此创建一个新的 SSLContext 对象将完全破坏 [in] 连接池中的现有连接”只是一种猜测，而不是既定事实。

标签： java ssl sslengine sslcontext ultraesb

【解决方案1】：

你需要考虑清楚。如果您已建立连接，则它已经成功地进行了证书交换，因此它不需要新证书，因此不需要新的或重新初始化的SSLContext，直到并包括部分握手，例如更新当前会话的密钥，或请求客户端证书。除了完全握手之外，它根本不应该使用 SSLContext。

您需要做的是开始为所有需要新证书的new 连接使用new SSLContext。根据定义，您无需对现有连接执行任何操作。

【讨论】：

很抱歉给您带来了困惑。我更新了它。我正在传递SSLContext 对象。我想知道的是，使用SSLEngine 对象进行包装和展开的现有套接字连接是否会受到更改SSLContext 对象的信任管理器的影响。仅在已收到请求但尚未发送响应的情况下才会出现问题。是否有可能使用一组密钥对传入连接进行解包，并使用一组单独的密钥对响应进行封装，这会中断通信是上述情况吗？
会话密钥在SSLSession，而不是SSLContext，但我仍然不明白您为什么认为需要重新初始化现有连接的`SSLContext。
这意味着，SSLEngine 仅使用SSLContext 进行握手。因此，之后，SSLContext 的更改不会影响连接/套接字的现有SSLSession 或SSLEngine（如果不是握手）。我说的对吗？
据我所知，这应该是正确的。如果是部分握手，例如要重新生成当前会话的密钥或请求客户端证书，它根本不应该使用 SSLContext。
好的。谢谢你的帮助。您能否将该部分也添加到答案中，以便我可以接受它作为答案:)