“… an error occurred during the pre-login handshake.” & “[DBNETLIB][ConnectionOpen (SECDoClientHandshake()).]SSL Security error” when connecting to SQL Server.


This blog is regarding one of most commonly faced issues that you may receive when connecting to the SQL Server. Mostly you may run into this issue after some improper Windows security update (say KB2655992 in my case) or improper application of Poodle security fix.

 

ISSUE DESCRIPTION FROM SQL CONNECTIVITY STANDPOINT:

When we try to connect to the SQL Server instance using the SQL Server Management Studio, it may fail with the following error message,

Error:

TITLE: Connect to Server

——————————

Cannot connect to <mySQLServer>.

——————————

ADDITIONAL INFORMATION: 

A connection was successfully established with the server, but then an error occurred during the pre-login handshake. (provider: Shared Memory Provider, error: 0 – No process is on the other end of the pipe.) (Microsoft SQL Server, Error: 233)

For help, click: http://go.microsoft.com/fwlink?ProdName=Microsoft+SQL+Server&EvtSrc=MSSQLServer&EvtID=233&LinkId=20476

 ——————————

BUTTONS:

OK

——————————

 

Using a UDL file, we saw the following error message,

—————————

Microsoft Data Link Error

—————————

Test connection failed because of an error in initializing provider. [DBNETLIB][ConnectionOpen (SECDoClientHandshake()).]SSL Security error.

—————————

OK  

————————— 

 

Note: Forcing the connection to use any other protocol like TCP, Named Pipes & Shared Memory also throws the same error message. The Dedicated administrator connection (DAC) was also throwing a “Login timeout expired.” error.

 

OUR FINDINGS & INFERENCE:

 

There are numerous reasons on why you may witness these error messages. But usually, if you see these 2 specific error messages from SQL Server Management Studio & UDL file. Then it is worth checking the below settings.

 

As per the error message received, “… an error occurred during the pre-login handshake.” and “[DBNETLIB][ConnectionOpen (SECDoClientHandshake()).]SSL Security error.” means that the client application was able to complete the TCP 3-way handshake properly (hence you notice “A connection was successfully established with the server”), but during the pre-login handshake,  the client application checks with the SQL Server on the TDS protocol version to be used henceforth for the communication, the login passed by the client application (Windows authenticated login or SQL Authenticated Login), whether there is any client-side or SQL Server connection encryption using SSL certificates or TLS etc. If the SQL Server doesn’t respond to this request from the client in a timely fashion or fails to respond due to any internal machine-level issues, we end-up at this particular error message. (wiz. “… an error occurred during the pre-login handshake”)

 

These error messages are thrown from the actual SQL Server drivers / providers that are used to establish the connection to the SQL server. E.g (OLE DB provider for SQL Server / SQL Server Native Client etc.). So different SQL Drivers/ Providers throws different error messages for the same issue. When we tried the connection from the UDL file, we see a different error message for this reason, but this error message was more straightforward.

 

Error:

Test connection failed because of an error in initializing provider. [DBNETLIB][ConnectionOpen (SECDoClientHandshake()).]SSL Security error.

 

Hence, we directly jumped to the SCHANNEL registry hive to check the values. Wiz.

Target hive:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

 

CAUSE:

 

By default, you may not find the below registry keys, which is completely fine. But  in my case, when we checked the values for these registry keys on the target SQL Server, the following were the values.

 

i) HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server

DisabledByDefault  was set to 1

Enabled  was set to 0

 

ii) HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server

DisabledByDefault  was set to 1

Enabled  was set to 0 

 

iii) HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0 \Server

DisabledByDefault  was set to 0

Enabled  was set to 0 

 

Based on these values, we figured-out that none of the security provider protocols were enabled. We confirmed that all SSL 2.0, SSL 3.0 & TLS 1.0 were disabled and this is not an ideal scenario.

 

RESOLUTION:

 

We enabled the TLS 1.0 protocol by setting the following value.

Under,

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0 \Server

Set Enabled to 1

 

Rebooted the SQL Server machine for the changes to reflect.

After the successful reboot, we were able to connect to the SQL Server locally without any issues. Also tested the connection from a remote server machine and confirmed that the connections to the SQL Server worked as expected without any issues. SQL server was just a victim here like any other application that uses windows security providers and since all the security provider’s protocols were disabled, the SQL Server wasn’t able to accept any new connection request.

 

 

Please drop in your comments or connect with Microsoft BI-ONE CSS team if you are still encountering the same issue even after performing the above steps.

Happy troubleshooting!!!!

 

Author: Krishnakumar Rukmangathan, Technical Advisor, SQL Server BI-ONE Developer team, Microsoft

Reviewed by: Sunil Kumar B.S, Escalation Engineer, SQL Server BI-ONE Developer team, Microsoft.

Comments (5)

  1. Claudio says:

    Hello I have performed all the steps and still receive the error, i´m using Microsoft Data Link, any help would be appreciated. thanks.

  2. Krishnakumar Rukmangathan (MSFT) says:

    Hi Claudio,

    Can you post the exact error message and text content of the backup of the registry key

    HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNEL

    on the failing server.

  3. Jim says:

    Grateful for this post. I have enabled TLS 1.0 and the problem has been resolved. We found that we have disabled SSL & TLS because of some “hardening” measures.

  4. Darren Myher says:

    PCI DSS Rules now forbid the use of TLS 1.0
    http://blog.pcisecuritystandards.org/migrating-from-ssl-and-early-tls
    “Consistent with the existing language in PCI DSS v3.1, all new implementations must be enabled with TLS 1.1 or greater. TLS 1.2 is recommended.”

    Are you suggesting that ODBC cannot be made to work at all if TLS 1.0 is disabled? If so, no organization that uses ODBC will be able to pass a PCI Scan and we all have a major problem on our hands.

    1. payaxy says:

      I’d be also interested to know the position of MS on supporting TLS 1.2 in light of requirements coming from PCI compliance

Skip to main content