“… 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: https://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.