We have a system that needs to provide both database and web services. We want to lock down the TLS security settings to the highest degree possible. It's running MS SQL 2008 on Windows Server 2008 R2.

I know that SQL Server 2008 does not support any protocol higher than TLS 1.0. However, I would still like the web service to reject incoming TLS 1.0 negotiation attempts. Best I can tell though, both seem to be controlled through the same SCHANNEL registry keys.

Is there any way to separately control TLS negotiation for MSSQL and IIS, on the same system, such that MSSQL is allowed to use TLS 1.0 but IIS is forced to only TLS 1.1/1.2?

  • Why not use ipsec? – Jim B Oct 21 '15 at 22:48
  • @JimB We thought of that too. Probably going to be brought up in our next discussion on the topic. But I was kind-of hoping there was an "easier" fix along these lines. – Iszi Oct 21 '15 at 23:26

This is a common annoyance not limited to SQL but might also occur if your webservers need to connect to third parties that don't support TLS 1.1 or 1.2 (webservices, etc.). The way we get around this is with a load balancer (MS ARR) in-front of the web servers. The ARR node has the SSL config locked down to only support TLS 1.1 and 1.2, but TLS 1.0 is still enabled on the actual web nodes. The ARR cluster sites in the DMZ and proxies to the webservers in another zone.


Windows servers all make use of the SCHANNEL security provider. The only way that you could potentially get around this would be if at least one of your products provided their own security providers. Neither IIS or MSSSQL do this. I haven't seen a single Microsoft product that does.

I suggest you bite the bullet and segment this to two servers. If the physical hardware is a concern look at setting up hyperv and two VMs.

Failing that you might find that setting up a reverse proxy of some sort - say Apache - might get you by.

  • If there's really no way to separately control TLS for the two services, segmenting is one option - and would address other "best practice issues" - but I think the real "bite the bullet" that we should probably be looking at is upgrading the MSSQL software to something TLS 1.1/1.2-compatible. That's also under discussion, but I'm hoping to figure something else out for the interim too. – Iszi Oct 21 '15 at 21:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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