Java 8上的SQL Server JDBC错误：驱动程序无法通过使用安全套接字层（SSL）加密建立到SQL Server的安全连接

Question

使用Microsoft JDBC驱动程序版本连接到SQL Server数据库时，出现以下错误：

com.microsoft.sqlserver.jdbc.SQLServerException：驱动程序无法通过使用安全套接字层（SSL）加密建立到SQL
Server的安全连接。错误：“ SQL
Server返回的响应不完整。连接已关闭。ClientConnectionId：98d0b6f4-f3ca-4683-939e-7c0a0fca5931”。

最近，我们将应用程序从Java 6和Java 7升级到了Java8。所有运行Java的系统都在运行SUSE Linux Enterprise Server
11（x86_64），VERSION = 11，PATCHLEVEL = 3。

这是我使用编写的Java程序收集的事实，该程序简单地依次打开和关闭1,000个数据库连接。

• 约有5％-10％的时间断开连接并出现此错误。该错误不会在每个连接上都发生。
• 该问题仅在Java 8中出现。我在Java 7上运行了相同的程序，并且该问题无法重现。这与我们升级之前的生产经验一致。在生产环境中使用Java 7运行时，我们零遇到问题。
• 该问题不会在我们所有运行Java 8的Linux服务器上发生，仅在其中一些服务器上会发生。这让我感到困惑，但是当我在不同的Linux实例上的相同版本的Linux JVM（1.8.0_60，64位）上运行相同的测试程序时，在一个Linux实例上不会发生此问题，但是问题是确实发生在其他人身上。Linux实例运行相同版本的SUSE，并且具有相同的补丁程序级别。
• 当同时连接到SQL Server 2008和SQL Server 2014服务器/数据库时，会发生此问题。
• 无论我使用的是SQL Server JDBC驱动程序的4.0版本还是驱动程序的较新版本4.1，都将发生问题。

与网上其他人相比，使我的观点独特的是，尽管问题仅发生在Java 8上，但我无法在运行相同Java 8
JVM的看似相同的Linux服务器之一上发生该问题。其他人也已经在Java的早期版本中看到了此问题，但这并不是我们的经验。

您可能会提出的任何建议，建议或意见。

Answer 1

我在Linux实例上的Java 8 JVM中打开了SSL日志记录，从而重现了该问题。使用开启SSL日志记录
-Djavax.net.debug=ssl:handshake:verbose。这揭示了一些有用的信息。

该 解决方法 ，我们在生产中使用，并已被证明对我们的工作是建立在JVM上这个参数：

 -Djdk.tls.client.protocols=TLSv1

如果您需要更多详细信息，请继续阅读。

在可以重现问题的服务器上（再次，只有5-10％的时间），我观察到以下内容：

*** ClientHello, TLSv1.2
--- 8<-- SNIP -----
main, WRITE: TLSv1.2 Handshake, length = 195
main, READ: TLSv1.2 Handshake, length = 1130
*** ServerHello, TLSv1.2
--- 8<-- SNIP -----
%% Initialized:  [Session-79, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256]
** TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
--- 8<-- SNIP -----
Algorithm: [SHA1withRSA]
--- 8<-- SNIP -----
*** Diffie-Hellman ServerKeyExchange
--- 8<-- SNIP -----
*** ServerHelloDone
*** ClientKeyExchange, DH
--- 8<-- SNIP -----
main, WRITE: TLSv1.2 Handshake, length = 133
--- 8<-- SNIP -----
main, WRITE: TLSv1.2 Change Cipher Spec, length = 1
*** Finished
verify_data:  { 108, 116, 29, 115, 13, 26, 154, 198, 17, 125, 114, 166 }
***
main, WRITE: TLSv1.2 Handshake, length = 40
main, called close()
main, called closeInternal(true)
main, SEND TLSv1.2 ALERT:  warning, description = close_notify
main, WRITE: TLSv1.2 Alert, length = 26
main, called closeSocket(true)
main, waiting for close_notify or alert: state 5
main, received EOFException: ignored
main, called closeInternal(false)
main, close invoked again; state = 5
main, handling exception: java.io.IOException: SQL Server returned an incomplete response. The connection has been closed. ClientConnectionId:12a722b3-d61d-4ce4-8319-af049a0a4415

请注意， TLSv1.2
由数据库服务器选择并在此交换中使用。我观察到，当有问题的linux服务连接失败时，TLSv1.2始终是所选的级别。但是，使用TLSv1.2时，连接不会总是失败。他们只有5-10％的时间失败。

现在，这里是来自服务器的交换，没有问题。其他一切都是平等的。即，连接到相同的数据库，相同版本的JVM（Java
1.8.0_60），相同的JDBC驱动程序等。请注意，在此情况下，数据库服务器选择的是 TLSv1
，而不是有故障服务器的情况下选择的是TLSv1.2。

*** ClientHello, TLSv1.2
--- 8<-- SNIP -----
main, WRITE: TLSv1.2 Handshake, length = 207
main, READ: TLSv1 Handshake, length = 604
*** ServerHello, TLSv1
--- 8<-- SNIP -----
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA
--- 8<-- SNIP -----
%% Initialized:  [Session-79, TLS_RSA_WITH_AES_128_CBC_SHA]
** TLS_RSA_WITH_AES_128_CBC_SHA
--- 8<-- SNIP -----
Algorithm: [SHA1withRSA]
--- 8<-- SNIP -----
***
*** ServerHelloDone
*** ClientKeyExchange, RSA PreMasterSecret, TLSv1
--- 8<-- SNIP -----
main, WRITE: TLSv1 Handshake, length = 134
main, WRITE: TLSv1 Change Cipher Spec, length = 1
*** Finished
verify_data:  { 26, 155, 166, 89, 229, 193, 126, 39, 103, 206, 126, 21 }
***
main, WRITE: TLSv1 Handshake, length = 48
main, READ: TLSv1 Change Cipher Spec, length = 1
main, READ: TLSv1 Handshake, length = 48
*** Finished

因此，当在Linux JVM和SQL Server之间协商TLSv1时，连接总是成功的。协商TLSv1.2时，我们会遇到零星的连接失败。

（注意：Java 7（1.7.0_51）始终协商TLSv1，这就是为什么Java 7 JVM永远不会发生问题的原因。）

我们仍然有未解决的问题：

1. 原因是，从2个不同的Linux服务器运行的同一Java 8 JVM总是会协商TLSv1，但是从另一个Linux服务器连接时，它总是会协商TLSv1.2。
2. 还有为什么TLSv1.2协商的连接在该服务器上大多数（但不是全部）时间都成功？