com.microsoft.sqlserver.jdbc.sqlServerException: The driver could not establish a secure connection to sql Server by using Secure Sockets Layer (SSL) encryption. Error: “sql Server returned an incomplete response. The connection has been closed. ClientConnectionId:98d0b6f4-f3ca-4683-939e-7c0a0fca5931”.
我们最近从Java 6& Java 7到Java 8.运行Java的所有系统都运行SUSE Linux Enterprise Server 11(x86_64),VERSION = 11,PATCHLEVEL = 3.
这是我用Java程序收集的事实,我写的只是顺序打开和关闭1000个数据库连接.
>连接被删除,这个错误约5％-10％的时间.每个连接都不会出现错误.
>只有Java 8出现问题.我在Java 7上运行相同的程序,问题是不可重现的.这与升级前的生产经验是一致的.我们在生产中运行的Java 7中有零个问题.
>在所有运行Java 8的Linux服务器上都不会出现该问题,它只发生在其中一些.这对我来说很困惑,但是当我在不同的Linux实例上的相同版本的Linux JVM(1.8.0_60,64位)上运行相同的测试程序时,其中一个Linux实例上不会发生问题,但问题确实发生在别人身上. Linux实例正在运行相同版本的SUSE,并且它们处于相同的补丁级别.
>连接到BOTH sql Server 2008和sql Server 2014服务器/数据库时,会出现此问题.
>如果我使用4.0版本的sql Server JDBC驱动程序或更新的4.1版本的驱动程序,则会出现此问题.
与Web上的其他人相比,使我的观察独一无二的事情是,虽然问题只发生在Java 8上,但我不能在运行相同的Java 8 JVM的似乎相同的Linux服务器之间发生问题.其他人也在早期版本的Java上看到了这个问题,但这并不是我们的经验.
您可能会感谢任何输入,建议或观察.
解决方法
我们在生产中使用并已证明可以为我们工作的解决方法是在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,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,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,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,21 }
***
main,length = 48
main,READ: TLSv1 Change Cipher Spec,length = 1
main,length = 48
*** Finished
因此,当在Linux JVM和sql Server之间协商TLSv1时,连接总是成功的.当协商TLSv1.2时,我们得到零星的连接失败.
(注意：Java 7(1.7.0_51)总是协商TLSv1,这就是为什么我们使用Java 7 JVM的问题.)
我们还有的开放性问题是：
>为什么从两个不同的Linux服务器运行的相同的Java 8 JVM将始终协商TLSv1,但是当从另一个Linux服务器连接时,它始终协商TLSv1.2.
>而且为什么TLSv1.2协商连接在该服务器上最成功,但并非全部成功？
资源：
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
