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


Symptoms:

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,

Error:

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. ”

 
Background:

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).

 

Resolution/Workaround:

Please follow the below action plan in ascending order.

Option-1

  • 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.

https://www.microsoft.com/en-in/download/details.aspx?id=11774

 

Option-2

  • 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.

  1. Open Registry Editor.
  2. Access key exchange algorithm settings by navigating to the following registry location:HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\KeyExchangeAlgorithms
  3. Select the Diffie-Hellman sub key (if it does not exist, then create it).
  4. Set the Enabled DWORD registry value to 0 (if it does not exist, then create it).
  5. 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.

https://technet.microsoft.com/en-us/library/security/ms15-055.aspx

1

 

 

If above action plans (disabling the Diffie-Hellman Key Exchange ) doesn’t work then you can follow the below action plan.

 

Option-3

  • 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

 

Option-4

  • 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)

TLS_DHE_RSA_WITH_AES_128_CBC_SHA

TLS_RSA_WITH_AES_128_CBC_SHA

 

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

 

Comments (1)

  1. Marnix Klooster says:

    Could you perhaps provide more detail on what those “some recent Microsoft updates” are?

    I’m asking because a customer of us is running into this, and we’d like to replicate the issue to be able to document it properly.

    Thanks!!

Skip to main content