This question already has an answer here:

Background

We need PCI-DSS compliance, and so must disable TLS1.0. In my test environment we have SQL Server 2014 SP1 with CU 1 (as per this post) and IIS 8 all on the same box. I used the Nartac IIS Crypto tool to disable TLS1.0 and rebooted. That's when my troubles began.

SQL Agent won't start, SSMS can't connect to the server, and the website stops working. (Fortunately, I can still make a Remote Desktop Connection to my test server.)

Then I read Microsoft's article which says basically SQL Server just has to have TLS1.0.

Question

Can I fix this? (Maybe I need a separate box in test for SQL Server?)

marked as duplicate by Paul White sql-server Jan 30 '16 at 5:04

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

I've resolved my problem. Not sure if all of the hurdles are things DBAs would normally encounter, but since people are often interested in resolving the whole problem, and this seemed like a series of issues others might encounter (given the various sources of the problems), here goes:

  1. Put IIS on a separate box. This allows IIS to have TLS1.0 disabled while SQL Server has it enabled.

  2. Disable TLS1.0 on the IIS box using John Louros' PowerShell script (not NARTAC's IISCrypto tool).

  3. At this stage I started getting System.InvalidOperationException: This implementation is not part of the Windows Platform FIPS validated cryptographic algorithms.. FIPS-compliance is on by default for .NET apps, so others may well encounter this. Since I didn't need FIPS compliance, I tried adding <enforceFIPSPolicy enabled="false"/> to web.config as per this post, which didn't fix the problem. I then followed the accepted answer from this post. I later ran into difficulties, and undid both these changes but the FIPS error didn't recur. Sorry, that's not very enlightening.

  4. Then I got System.Security.Cryptography.CryptographicException, which I fixed by changing web.config as suggested here. I replaced <machineKey validationKey="AutoGenerate,IsolateApps" decryptionKey="AutoGenerate,IsolateApps" validation="3DES" decryption="3DES"/> (which was suggested in this old Microsoft KB article) with <machineKey validationKey="AutoGenerate,IsolateApps" decryptionKey="AutoGenerate,IsolateApps" validation="HMACSHA256" decryption="AES" />.

Then - hurrah! - everything was working again.

Edit

I read Aaron Bertrand's post which refers to this answer. For anyone coming here from there, I should point out that my testing was before Microsoft's late-January-2016 announcement of TLS1.2 support. I'll try to get around to re-testing with any updates I didn't previously have from that announcement and with IIS and SQL on the same box again, and post my findings here.

(I'm not especially optimistic about being able to co-locate IIS and SQL because from what I had read, I already had TLS1.1 and TLS1.2 support in SQL Server 2014 due to having SP1 CU1, so these latest updates aren't adding anything new in theory. Also, I have an un-tested hunch that since IIS and SQL are on separate boxes, I could have any old version of SQL Server, without needing TLS1.1 support. If anyone has any thoughts on that I'd be glad to hear them.)

Not the answer you're looking for? Browse other questions tagged or ask your own question.