Java 间歇性SSL握手错误

我们有一个SSL问题，我是99%，这不是你通常的证书信任商店旋转木马

我们有一个Weblogic服务器试图通过LDAPS与Active Directory建立SSL连接，底层SSL实现是JSSE

有时，它是有效的。通常在重新启动Weblogic后的几个小时内

之后，我们开始获取SSL握手错误，打开SSL调试后，我们会看到：

[ACTIVE]ExecuteThread:'10'用于队列：'weblogic.kernel.Default' （自调优），处理异常：java.net.SocketException: 队列的连接重置[ACTIVE]ExecuteThread:“10”： “weblogic.kernel.Default（自调优）”，发送TLSv1警报：致命， description=意外消息[ACTIVE]ExecuteThread:'10'用于 队列：“weblogic.kernel.Default（自调优）”，写入：TLSv1警报， 长度=32[ACTIVE]ExecuteThread:“10”用于队列： “weblogic.kernel.Default（自调优）”，异常发送警报： java.net.SocketException:管道破裂

到目前为止，我尝试了以下方法来理解/复制它：

• 通过OpenSSL连接并加载证书-每次都正常工作
• 通过安全ldapsearch连接并加载证书-每次都正常工作
• 通过自定义测试Java客户端连接-每次都正常工作
• 使用Wireshark和私钥解密SSL握手

我注意到Wireshark的“坏”握手，在客户端发送了一个更改密码规范后，完成的消息广告不会以实物形式回复。此外，Wireshark无法解密SSL握手，失败原因如下：

ssl_decrypt_pre_master_secret错误的pre_master_secret长度（109， 应为48）解析\u ssl3\u握手无法解密预主密钥

注意：当SSL握手工作正常时，Wireshark SSL解密工作正常

我看不出SSL握手的好坏有什么显著区别，直到AD服务器没有响应为止

在这一点上，我被难住了。。。我真的很难理解为什么这会在一段时间内失败，而在剩下的时间里会奏效，在这一点上，我真的只是希望得到一些关于可能发生的事情的建议

哦，是的，差点忘了。Active Directory事件日志中存在错误：

事件ID:36888引发了以下致命警报：20。国家 内部错误是960

经过一番研究，我发现这与SSL“BAD_RECORD_MAC”错误相对应

在这一点上，我唯一的理论是，出于某种原因，错误的公钥被用来加密握手。。。我不明白为什么服务器（和Wireshark）无法解密完成的消息

谢谢

更新：

---

我比较了好的和坏的情况，这两种情况下的密码规格是相同的：TLS_RSA_与_AES_128_CBC_SHA。我还比较了客户端和服务器端的数据包，排除了正常的以太网和IP协议差异，它们看起来都是相同的。

据我所知，问题是间歇性的。也就是说，您可以通过SSL连接到AD，但偶尔会注意到此错误。所以我想证书问题不是你的问题

根据你的描述，我只能想到以下几点：
首先，你在这里没有给出太多的实际细节，但你的评论是：

注意：当SSL握手时，Wireshark SSL解密可以完美地工作 工作完美

给我一个提示，密码套件在坏的情况下是不同的。请注意，即使您拥有私钥，wireshark也无法通过DHE生成的密钥解密连接。
因此，您应该在调查中查看密码套件在好坏情况下是否确实不同（例如RSA与DHE）。

---

此外，从您描述的方式来看，问题似乎发生在重新谈判过程中。也许重新协商已禁用，您可以启用它？它被认为是不安全的，通常可以在服务器中配置，所以经过大量的研究、实验和自我反省。我们最终追踪到了一个第三方库，该库用于连接外部系统。初始化时，它将在JSSE默认提供程序之前添加自身作为安全提供程序。我不知道这到底是为什么，然后继续打破所有后续的SSL连接。。。但确实如此

---

谢谢你的帮助。

我知道细节不够详细，但我得小心一点。我会尽力的。现在，尽管我很感激任何建议，但我也应该澄清间歇的含义。通常，重新启动Weblogic后，它可以正常工作几个小时。似乎没有固定的时间框架，但很难确定。在某些情况下，它会停止工作，并且通常会一直处于故障状态，直到有人重新启动服务器。根据提供的数据，这很难诊断。我建议从cert子系统获取一些日志记录，并并行进行网络嗅探（即wireshark或类似）。那会有帮助的。。。