Dbnetlib connectionopen secdoclienthandshake ошибка безопасности ssl

This article, suggests a way of resolving the below error message, when you are trying to access SQL Server using “Microsoft OLE DB Provider for SQL Server” and TLS 1.0: [DBNETLIB] [ConnectionOpen (SECDoClientHandshake()).] SSL Security Error

Prior to start writing this article, I was thinking of using a title like “How to still use TLS 1.0”, or something similar, but besides the fact that would have given a wrong message, it would not help so much because many people, usually search for such articles using the error message (SSL Security error)…

So, I anticipate that this article, with this title, would help as many people as possible 🙂

Drop me a line if you find the article useful and why not, subscribe to my newsletter to stay up to date with future articles!

A Few Words About TLS 1.0

TLS 1.0 is considered a deprecated protocol and it is not recommended anymore to be used to secure connections. That’s why many organizations (if not all) transitioned or are in the process of transitioning to newer versions of TLS such as TLS1.1 or above.

However, you may still encounter outdated applications that still need to use this protocol, even for a while for just performing a single operation. One such example, is to try and connect to a SQL Server instance via Microsoft OLE DB Driver for SQL Server using TLS 1.0.

If you are in such situation, I have good news, from a technical aspect, it is still possible to do this.

Read on to learn more.

SQL Server Support for TLS 1.0 and Above

SQL Server still supports all TLS protocols, currently from 1.0 to 1.2. However, depending on the version of SQL Server you have, especially in cases of older SQL Server versions, you might need a patch.

Read this article on SQLNetHub to learn more about SQL Server support for TLS versions.

Now let’s jump to the juicy part of this article and see how finally we can resolve the above error and manage to connect to SQL Server using Microsoft OLE DB Driver for SQL Server and TLS 1.0.

Note that if you are just trying to connect with TLS 1.0 for a while in order to perform a specific task, then make sure to revert the below changes in order to restore the security level of your systems back to their previous level.

Latest Microsoft OLE DB Driver for SQL Server

The first step towards resolving the SSL Security error, is to make sure that the version of the target SQL Server instance you want to connect to, is supported by the driver.

For example, Microsoft OLE DB Driver 18.1 for SQL Server supports connecting to SQL Server 2012 or later.

For older versions of SQL Server, you will need to find an earlier version of Microsoft OLE DB Provider for SQL Server as well.

You can find the latest version of the OLE DB driver here.

Useful details:

The Microsoft OLE DB Provider for SQL Server, allows ADO to access Microsoft SQL Server. However, This is an older driver and it is not recommended to be used driver for new development, since it is deprecated.

The new OLE DB provider is called the Microsoft OLE DB Driver for SQL Server (MSOLEDBSQL) which will be updated with the most recent server features going forward (learn more)

Registry Changes

The next step is, to edit the Windows Registry (* always be careful when messing up with Windows Registry – only certified engineers should do that).

To enable TLS 1.0 in Windows

In Windows Registry, add the below dword keys:

[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTLS 1.0Server]

• “Enabled”=dword:00000001
• “DisabledByDefault”=dword:00000000

[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTLS 1.0Client]

• “Enabled”=dword:00000001
• “DisabledByDefault”=dword:00000000

To disable TLS 1.0 in Windows

[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTLS 1.1Server]

• “Enabled”=dword:00000000
• “DisabledByDefault”=dword:00000001

[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTLS 1.1Client]

• “Enabled”=dword:00000000
• “DisabledByDefault”=dword:00000001

Learn more about the above registry changes in this MS Docs article.

Local Security Policy

The next step is to check the Local Security Policy on the database server.

So, in Local Security Policy on the Database Server, make sure that the setting “System Cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing” is disabled.

If you want to learn more about this security option, you can check this MS Docs article.

Strengthen your SQL Server Administration Skills – Enroll to our Online Course!

Check our online course on Udemy titled “Essential SQL Server Administration Tips”
(special limited-time discount included in link).

Via the course, you will learn essential hands-on SQL Server Administration tips on SQL Server maintenance, security, performance, integration, error handling and more. Many live demonstrations and downloadable resources included!

Enroll from $12.99

Server Protocols, Ciphers, Hashes and Client Protocols

The last step in this troubleshooting guide, is to use IISCrypto, which is an excellent free tool, that allows you to control which protocols, ciphers, and more are enabled (or not) on a Windows server.

That being set, you will need to run IISCrypto and make sure that the “TLS 1.0” Server and Client Protocols, as well as the”SHA” hash are enabled.

Here’s a screenshot of IISCrypto, running on my PC, having TLS 1.0 and “SHA” enabled for illustration purposes:

Note that, if finally you need to perform any changes using IISCrypto, you will need to restart the server.

Actually, for any changes you might need to perform, it is recommended to restart the server.

A Piece of Advice

As mentioned in this article’s beginning, TLS 1.0 is considered a deprecated protocol and it is not recommended anymore to be used to secure connections.

Instead, you should be using newer versions of TLS.

In case you just need to switch to TLS 1.0 for performing an ad hoc task, you need to make sure that after you completed the task, you revoked any changes you might have applied, and disable again TLS 1.0 and the “SHA” hash.

See More

Check out DBA Security Advisor, a SQL Server security tool to assess your SQL Server instances against a rich set of security checks and get security best practice recommendations.

Featured Online Courses:

• SQL Server 2022: What’s New – New and Enhanced Features [New]
• Data Management for Beginners – Main Principles
• Introduction to Azure Database for MySQL
• Working with Python on Windows and SQL Server Databases
• Boost SQL Server Database Performance with In-Memory OLTP
• Introduction to Azure SQL Database for Beginners
• Essential SQL Server Administration Tips
• SQL Server Fundamentals – SQL Database for Beginners
• Essential SQL Server Development Tips for SQL Developers
• Introduction to Computer Programming for Beginners
• .NET Programming for Beginners – Windows Forms with C#
• SQL Server 2019: What’s New – New and Enhanced Features
• Entity Framework: Getting Started – Complete Beginners Guide
• A Guide on How to Start and Monetize a Successful Blog
• Data Management for Beginners – Main Principles

Read Also

• DBA Security Advisor v2.3 is Now Out!
• The OLE DB provider “SQLNCLI11” for linked server “…” supplied inconsistent metadata for a column… – How to Resolve
• SQL Server 2022: What’s New – New and Enhanced Features (Course Preview)
• How to Connect to SQL Server Databases from a Python Program
• What is Data Security and which are its Main Characteristics?
• Introduction to Azure Database for MySQL (Course Preview)
• Data Management for Beginners – Main Principles (Course Preview)

Other SQL Server Security-Related Articles

• How to Enable SSL Certificate-Based Encryption on a SQL Server Failover Cluster
• Why You Need to Secure Your SQL Server Instances
• Policy-Based Management in SQL Server
• Should Windows “Built-InAdministrators” Group be SQL Server SysAdmins?
• Frequent Password Expiration: Time to Revise it?
• The “Public” Database Role in SQL Server
• Encrypting SQL Server Databases
• 10 Facts About SQL Server Transparent Data Encryption
• Encrypting a SQL Server Database Backup
• …check all

Subscribe to our newsletter and stay up to date!

Subscribe to our YouTube channel (SQLNetHub TV)

Easily generate snippets with Snippets Generator!

Secure your databases using DBA Security Advisor!

Generate dynamic T-SQL scripts with Dynamic SQL Generator!

Check our latest software releases!

Check our eBooks!

Rate this article: (8 votes, average: 5.00 out of 5)

Loading… 

Reference: SQLNetHub.com (https://www.sqlnethub.com)

© SQLNetHub

Views: 20,578

First published on MSDN on Jul 09, 2015

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&LinkI…

——————————

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_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNEL

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_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsSSL 2.0Server

DisabledByDefault

was set to 1

Enabled

was set to 0

ii)

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsSSL 3.0Server

DisabledByDefault

was set to 1

Enabled

was set to 0

iii)

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTLS 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_MACHINESYSTEMCurrentControlSetControlSecurityProvidersSCHANNELProtocolsTLS 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.

I recently upgraded a database server at a customer which has several pieces of manufacturing equipment that use PC-based controllers to connect to the database on the server.  After the upgrade, all of the XP-based controller machines are able to connect
to the database fine, but the oldest controller which has an NT4 OS on its hardware (it’s ordinary if very old PC hardware but has some proprietary hardware interfaces that control the piece of manufacturing equipment.)

The controller uses a UDL based connection to the server.  All of the XP controllers, as stated, can connect to the server.  On the NT 4 controller, a UDL connection attempt can see the database instance on the new server but attempting to enumerate
the databases yields the following error:

[DBNETLIB][ConnectionOpen (SECDoClientHandshake()).]SSL Security error.

Software version information follows:

Client:  NT4 Workstation is using  MDAC 2.8 SP1, Dbnetlib.dll 2000.85.1117.0

Microsoft SQL Server Build  2009.100.2500.0, product version 10.50.2500.0

dbnetlib.dll                                                         2000.86.3959.0

SSL Security error [DBNETLIB]ConnectionOpen (SECDoClientHandshake())

This particular resolution is one of its own kind their could have been other possibilites for his error message to raise, generally it comes if you have Expired Certificates or invalid Certificates on the Server for the user account or the computer account, delete the unwanted Certificates on the server and then try to start SQL or Connect should work

Other times this message comes if you had encryption enabled for the Server sometime but no more now, but then internally we are still finding the certificate somehow, though you anyways dont need the SSL certificate, so go to the following Registry and check for the Certificate value it should be EMPTY, but if it has ThumbPrint value of the Certifcate it is a problem, go ahead and make the change for Certificate value set to 0

HKLMSOFTWAREMicrosoftMSSQLServerMSSQLServerSuperSocketNetLib REG_SZ Certificate=0

Coming back to this unique problem:

Problem Description:
=================
Trying to enable SSL encryption for sql server connections on server
Went through the steps detailed in article 276553 ( http://support.microsoft.com/? >).

From one client we were unable to connect to the SQL Server 2000 using encrypted connections . From our own desktop workstation , along with that of one of the other Clients box they are unable to connect to the SQL Server through encrypted connections.

Consistently receive the following error:
[DBNETLIB]SSL Security error[DBNETLIB]ConnectionOpen (SECDoClientHandshake()).

The certificate chains are identical on both machines.

We Enabled odbc tracing and attempted to login again from his local box. The log of that attempt is enclosed. It contains the following information:

osql -Sact-dd01 2764-1a88 EXIT SQLDriverConnectW with return code -1 (SQL_ERROR) HDBC 009A1830 HWND 00000000 WCHAR * 0x74329A38 [ -3] «****** 0» SWORD -3 WCHAR * 0x74329A38 SWORD 2 SWORD * 0x00000000 UWORD 0
DIAG [08001] [Microsoft][ODBC SQL Server Driver][DBNETLIB]SSL Security error (18)
DIAG [01000] [Microsoft][ODBC SQL Server Driver][DBNETLIB]ConnectionOpen (SECDoClientHandshake()). (271)
Operating System:Windows 2003 : where the Encrypted Client connections are working
Operating System: Windows XP Sp2 and Windows 2000 SP4 where the Client connections are not working using Encryption, though if the encryption is not enabled the connections will flow fine

Cause
=====
The cause is a DBNETLIB.DLL , the version compatibility of this DLL on the XP and Windows 2000 is the possible culprit, i dont think it is a BUG

2) Now Check the Version for the same DLL on the Windows XP Sp2 and Windows 2000 Sp4 box

In My case the Windows XP SP2 had the following version of the DBNETLIB.DLL
Version: 2000.85.1117.0

The Windows 2000 SP4 box had the follwoing DLL version in my case
Version: 2000.85.1064.0

4) So what i did was, i copied the DLL Version: 2000.86.1830.0 from the Windows 2003 SP1 box to the Windows Xp SP2 box and also to the Windows 2000 SP4 Box

Went to the following location on the Windows XP Sp2 box:

C:windowssystem32 and renamed the existing DBNETLIB.DLL to DBNETLIB.DLL.OLD
After that pasted the copied DLL version 2000.86.1830.0 on the XP Sp2 box in the following location c:windowssystem32DBNETLIB.DLL <2000.86.1830.0>after that did a refresh and saw that the Version got back to the older version that is 2000.85.1117.0. Made a check in the DLLCACHE and saw that the DBNETLIB.DLL was present there and was having the Version 2000.85.1117.0 , hence First paste the DBNETLIB.DLL in the DLLCACHE and then replace the actual DLL inside the c:windowssystem32.

Do a refresh and see if the DLL version is Showing as 2000.86.1830.0 on the XP Sp2 Box.

The above resolved the issue with the SSL encryption errors, and the Secured channel is established

5) Repeat the above Steps for a Windows 2000 SP4 box, and this should help in getting past through the problem

NOTE: Never try to Register this DLL, also it wont let you as well, as it is not a COM DLL, also replacing this DLL will never break anything as it is a System DLL and the version is upgraded through MDAC

can this article be re written by someone who actually speaks english? The grammer is so bad is difficult to understand what they mean.

I don’t care if this blog is written in English or not!! Hats off to this guy! thank you, this solution actually works!! ��

@ber5ien | IT Professional | Personal Blog

I have recently have this issue on SQL Server 2012 with Windows Server 2012 R2.

The error was displayed one using OLE DP Provider in the VB script connection strings.
After looking at various google post explaining this issue nothing has worked.

To confirm the server is PCI DSS compliant and TLS 1.0

this is to use native SQL Client Drivers to connect.

This has worked and no more issues the script complained.

Our ASP/IIS web server talks to a SQL 2005 db server.

Eventually, without a pattern, some pages start showing error instead of the page content:

[DBNETLIB][ConnectionOpen (SECDoClientHandshake()).]SSL Security error.

Rebooting web server resolves it.

Anyone know about it?

2 Answers 2

Some things you should look at:

• Low bandwidth to the DB server (see http://support.microsoft.com/kb/322144)
• Problematic certificates on the DB server, e.g. self-signed certificates
• SQL Authentication mode — Windows only, or SQL and Windows

In case others happen to come across this when their certs expire and wonder why their SQL Server is giving SSL errors.

This worked for me after removing unwanted certs. setting Certificate=0 in registry:

HKLMSOFTWAREMicrosoftMSSQLServerMSSQLServerSuperSocketNetLib REG_SZ Certificate=0

Not the answer you’re looking for? Browse other questions tagged iis asp-classic ado ssl-security or ask your own question.

Hot Network Questions

To subscribe to this RSS feed, copy and paste this URL into your RSS reader.

site design / logo © 2019 Stack Exchange Inc; user contributions licensed under cc by-sa 4.0 with attribution required. rev 2019.11.15.35459