Let’s talk about TLS 1.2 Support for SQL Server. You may have seen the errors below when trying to start SQL Server after a reboot, or trying to connect to SQL Server:

The client and server cannot communicate, because they do not possess a common algorithm

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)

TDSSNIClient initialization failed with error 0x80090331, status code 0x80. Reason: Unable to initialize SSL support. The client and server cannot communicate, because they do not possess a common algorithm

The reason for this is that you may have disabled SSL 3.0 or TLS 1.0 on either the client side or SQL Server machine. The default SCHANNEL Protocols for any Windows OS has nothing but a key disabling SSL 2.0 client side. If you see anything different, this has been a manual change, either by GPO or by another user:


Background information on SCHANNEL Protocols with SQL Server

Before SQL Server 2016, SQL Server products out of the box only supported SSL 3.0 and TLS 1.0. It was only recently that the SQL Server products were upgraded to handle TLS 1.1 and TLS 1.2 Protocols. This means that if you are not upgraded to a version that supports TLS 1.2, disabling either of the old protocols meant failures with SQL Server.

If you are wondering why SSL matters at all, because “I’m not using SSL Certificates to bind my SQL Server or Reporting Services”, it still does! When connecting to SQL Server, your login information will always be encrypted, with or without your own SSL Certificate. SQL Server will use its self-signed certificate to encrypt login packets if encryption is not set on either the client or the server.


If you see in the registry that you have disabled TLS 1.0 or SSL 3.0, and you are having connectivity issues with SQL Server that points to SSL errors, you have a couple of options. Namely:

1. Change the registry to enable TLS 1.0 and SSL 3.0
2. Upgrade SQL Server and the client components to a supported build to handle TLS 1.2

DISCLAIMER: Change your registry settings at your own risk. Serious problems might occur if you modify the registry incorrectly. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. I don’t recommend anyone changing their registry keys without fully knowing what they will do. If you do make changes to the registry, those settings will only take effect after a reboot.

Since PCI Compliance rules have been published to disable TLS 1.0 and SSL 3.0, you may have been caught unaware of these changes made by your Security Admins. You might not be able to follow #1 above, and so your only option is to upgrade.


Follow the above article to upgrade both the client components, and SQL Server so that both sides are supported to communicate over TLS 1.2. If you are unsure of which client components need to be upgraded, follow my next article on this topic, and I will explain all about it.

One final note I would like to make is that you could very well have updated all components of SQL Server to support TLS 1.2, but still get the errors in this blog. The next piece of this puzzle is related to Cipher Suites, and I will discuss this in a later post.