We get it, your boss won’t stop talking about PCI Compliance, and now you have to disable SSL 3.0 and TLS 1.0 on your Windows Server machine, which may or may not accidentally shut off SQL. In order to prevent this from taking the step of partial disaster towards total disaster, all you need to do is a bit of registry hacking and bear with some SQL updates and reference changes. Basically, this article is all about how to keep SQL working with SSL 3.0 and TLS 1.0 disabled, to achieve PCI compliance or whatever else it may help you accomplish. Keep in mind that we made this article a little more fun than usual, but you’ll want to read it the whole way through in order to avoid some of the lessons we’ve learned.
To get started, you need to –
Step 1: create the following the keys under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\
“SSL 3.0” and “TLS 1.0”
Step 2: Then, under each of those, you further need to create 2 new keys:
“Client” and “Server”
Step 3: After that, under each of those, you must create 2 DWORD values named:
“DisabledByDefault” and “Enabled”. DisabledByDefault is assigned a value of 1, while Enabled is assigned a value of 0.
Note that the screenshots are for the server component values, but that the client component values are identical.
That was simple enough, right? After this, you need to reboot your server to make sure the registry key values are applied and find that all applications that had connections to your SQL 2008 server are no longer working despite the fact that none of them required an encrypted channel to SQL. A bit of digging and you see that SQL Server won’t even start. Panic.
You start googling for a solution and quickly realize that not all versions of SQL support disabling SSL 3.0 and TLS 1.0.
See this Microsoft article on TLS 1.0 and 1.2 for Microsoft SQL servers.
You bite the bullet and install SQL 2014 with the latest, greatest service pack. SQL server is running again, great. You check your applications needing SQL and see that they are still failing to connect to SQL. Back to more digging and you realize that you need to install SQL client-side components as well. Actually, the link you’d found earlier mentioned that, but you may not have read it thoroughly as you were panicking and rushing to get things working.
You quickly download and install ODBC Driver 11 for SQL server and also SQL Server Native Client for Server 2012.
You would think that would do it. You reboot your server just to be sure that all is good on startup, but it fails again. Some applications are still not connecting to SQL Server. Luckily you have access to their connection strings. You notice they look like: “ODBC:DRIVER=SQL Server; …”.
You realize that you are using the default SQL Server driver, not the new ones you just installed. You change the connection string to look like: “ODBC:DRIVER={SQL Server Native Client 11.0}; …” and restart the application that was not connecting to SQL. It connects! Life is good again.
Lesson learned.
So BEFORE you disable SSL 3.0 and TLS 1.0 on your Windows Server, be aware that there could be major consequences for your SQL Server. You should prepare for this scenario by:
(1) Updating your SQL Server to SQL Server 2014 with the latest service packs (or newer). According to the link posted above, SQL Server 2008 can also be patched by I did not try that scenario.
(2) You should then install or update your SQL Client components (ODBC Driver 11 for SQL server and SQL Server Native Client for Server 2012 for a SQL Server 2014 update). Note that the link above has details for the clients needed should you patch your existing SQL Server 2008.
(3) Update SQL connection strings to use the newly installed driver by using DRIVER={SQL Server Native Client 11.0} instead of DRIVER=SQL Server.
Hope this helps!
Leave a Comment