Intermittent JDBC Connectivity issue - 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
When connections are repeatedly made to SQL Server, one can observe about ~ 1% of connections having inability to connect. The user witnesses the following error message,
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. "
Due to some recent Microsoft updates, customer’s may experience connectivity issues to trading partners when using SSL / TLS to secure the connection. Recently, Microsoft has added two new ciphers to Windows, which use a different Key Algorithm. The minimum key length for allowed by these ciphers is 1024 characters. If the key length used by the trading partners is less than this, the SSL /TLS Handshake will fail.
The issue is only witnessed when using the older JDBC drivers below version 4.2. Other drivers works fine. We were unable to reproduce the issue when using Sqlclient/ADO.net stack (even when we forced a DHE suite).
Please perform the action plan below.
- Update the JDBC Driver to 4.2 or later version :
We implemented a workaround where the JDBC driver will retry the connection in the specific case where the SSL handshake receives an incomplete response from the Server.
Update the JDBC Driver to 4.2 or later version. This has a re-try logic inside. Make sure you have a supported JVM / JRE on that machine.
- Disable DHE cipher suites :
Warning: If you use Registry Editor incorrectly, you may cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that you can solve problems that result from using Registry Editor incorrectly. Use Registry Editor at your own risk.
- Open Registry Editor.
- Access key exchange algorithm settings by navigating to the following registry location:HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\KeyExchangeAlgorithms
- Select the Diffie-Hellman sub key (if it does not exist, then create it).
- Set the Enabled DWORD registry value to 0 (if it does not exist, then create it).
- Exit Registry Editor.
- Impact of the workaround: Encrypted TLS sessions that rely on DHE keys will no longer function unless alternative failover options have been implemented.
If above action plans (disabling the Diffie-Hellman Key Exchange ) doesn't work then you can follow the below action plan.
- DHE suites can be disabled in the JVM by opening up <JAVA_PATH>\jre\lib\security\java.security with admin privileges and add DHE to jdk.tls.disabledAlgorithms
- Change the SChannel cipher suite priorities to lower or disable or delete the DHE suites (as compared to something such as ECDHE, which works if they are present in both client & server)
If you have performed the above action plans and you are still experiencing the issue, then collect a network capture on the client and server reproducing the issue and contact the Microsoft CSS team for further investigation.
Author: Ranjit Mondal – Support Engineer, SQL Server BI Developer team, Microsoft
Reviewer: Krishnakumar Rukmangathan – Support Escalation Engineer, SQL Server BI Developer team, Microsoft