Question

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

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

我们最近从Java 6＆amp; Java 7到Java 8.所有运行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服务器/数据库时出现问题。
无论我使用的是4.0版本的SQL Server JDBC驱动程序还是较新的4.1版驱动程序，都会出现问题。

与网络上的其他人相比，使我的观察结果与众不同的是，尽管问题仅发生在Java 8上，但我无法在运行相同Java的看似相同的Linux服务器上发生问题。 8 JVM。其他人也在早期版本的Java上看到了这个问题，但这不是我们的经验。

您可能会对此提出任何意见，建议或观察。

Answer 1

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

我们在生产中使用的解决方法已证明适用于我们的是在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.2选择 TLSv1 就像在故障服务器的情况一样。

*** 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时从未发生过问题的原因。）

我们仍有的问题是：

为什么从2个不同的Linux服务器运行的相同Java 8 JVM将始终协商TLSv1，但是当从另一个Linux服务器连接时，它总是协商TLSv1.2。
为什么TLSv1.2协商连接在该服务器上的成功率最高，但不是全部？

更新6/10/2017： This posting from Microsoft描述了问题及其提出的解决方案。

<强>资源：

http://www.infoworld.com/article/2849292/operating-systems/more-patch-problems-reported-with-the-ms14-066-kb-2992611-winshock-mess.html

http://blogs.msdn.com/b/jdbcteam/archive/2008/09/09/the-driver-could-not-establish-a-secure-connection-to-sql-server-by-using-secure-sockets-layer-ssl-encryption.aspx

Java 8 , JCE Unlimited Strength Policy and SSL Handshake over TLS

http://blogs.msdn.com/b/saponsqlserver/archive/2013/05/10/analyzing-jdbc-connection-issues.aspx

https://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html#descPhase2

https://blogs.oracle.com/java-platform-group/entry/java_8_will_use_tls

Answer 2

这似乎已在MS SQL JDBC驱动程序的4.2版中得到修复。我创建了一个程序，我连接到服务器1000次，每次尝试之间暂停100ms。使用4.1版本，我每次都可以重现这个问题，尽管它偶尔会发生。在版本4.2中，我无法重现该问题。

Answer 3

在升级SQL JDBC驱动程序之前，请先检查兼容性：

Sqljdbc.jar要求JRE为5并支持JDBC 3.0 API
Sqljdbc4.jar要求JRE为6并支持JDBC 4.0 API
Sqljdbc41.jar要求JRE为7并支持JDBC 4.1 API
Sqljdbc42.jar需要JRE为8并支持JDBC 4.2 API

来源：https://www.microsoft.com/en-us/download/details.aspx?id=11774

Answer 4

微软最近开源了他们的驱动程序。可以在GitHub上看到mssql-jdbc驱动程序活动。我猜最新预览版是6.1.5。

您也可以在maven上找到所有预览版本。支持JDK7和JDK 8。

Answer 5

我也在Windows Server 2012 R2上使用JDBC驱动程序4.0＆amp; 4.1使用Java 7.这个Microsoft article将责任归咎于DHE密码套件，如果无法升级到JDBC驱动程序4.2，建议禁用它们或降低其优先级。

Answer 6

在我的情况下，我有一个使用3DES_EDE_CBC算法的sql服务器，默认情况下在jdk 1.8上将其禁用，因此请检查

/Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home/jre/lib/security/java.security

并从以下算法中删除该算法：

jdk.tls.disabledAlgorithms = SSLv3，RC4，DES，MD5和RSA，DH密钥大小< 1024， EC keySize <224，3DES_EDE_CBC，anon，NULL

为我工作。

Answer 7

如果连接字符串中的服务器名称与 SQL Server SSL 证书中的服务器名称不匹配，将发出以下错误：驱动程序无法通过使用安全套接字层 (SSL) 建立到 SQL Server 的安全连接加密。错误：“java.security.cert.CertificateException：在安全套接字层 (SSL) 初始化期间无法验证证书中的服务器名称。”

这帮我解决了这个问题。在servername中使用localhost，最后在jdbc连接字符串中更改为与CN能够连接的名称相同的名称。

参考：https://wiki.deepnetsecurity.com/pages/viewpage.action?pageId=1410867 了解更多信息

Answer 8

您的网址应如下所示，并添加sql sqljdbc42.jar。这样可以解决您的问题

url = "jdbc:sqlserver://" +serverName + ":1433;DatabaseName=" + dbName + ";encrypt=true;trustServerCertificate=true;

Answer 9

就我而言，问题是因为该应用程序设置为使用spring-boot-ext-security-starter-credhub-credential，并且该设置存在一些问题。

因此，我从清单文件和pom中删除了credhub，并以另一种方式获取了凭证。然后错误消失了。

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

9 个答案: