IIS 8.5 server not accepting a TLS 1.0 connection from Windows Server 2003

Question

(If you're wondering why I'm trying to enable cipher suites that are deprecated, the short answer is that it's for the few people who really can't use anything newer because they're stuck on Windows Server 2003, neither we nor them can do anything about it and we don't want the service we supply them with to stop working if we can help it.)

I have used IIS Crypto to enable a number of protocols, ciphers, hashes, key exchanges and cipher suites (here is a full listing) that should encompass what's necessary for our product to connect to this server over TLS 1.0 considering Schannel's capabilities in Windows Server 2003. (The server has been rebooted since the changes were applied in IIS Crypto.)

However, the server drops the connection and documents it with the following two event log entries, posted by Schannel in the System event log:

"An TLS 1.0 connection request was received from a remote client application, but none of the cipher suites supported by the client application are supported by the server. The SSL connection request has failed." - event ID 36874

followed by

"A fatal alert was generated and sent to the remote endpoint. This may result in termination of the connection. The TLS protocol defined fatal error code is 40. The Windows SChannel error state is 1205." - event ID 36888

Using Wireshark on the client, I can see that it is trying to negotiate the following cipher suites:

            Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004)
            Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005)
            Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
            Cipher Suite: TLS_RSA_WITH_DES_CBC_SHA (0x0009)
            Cipher Suite: TLS_RSA_EXPORT1024_WITH_RC4_56_SHA (0x0064)
            Cipher Suite: TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA (0x0062)
            Cipher Suite: TLS_RSA_EXPORT_WITH_RC4_40_MD5 (0x0003)
            Cipher Suite: TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 (0x0006)
            Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013)
            Cipher Suite: TLS_DHE_DSS_WITH_DES_CBC_SHA (0x0012)
            Cipher Suite: TLS_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA (0x0063)

of which these:

TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_RC4_128_MD5
TLS_RSA_WITH_3DES_EDE_CBC_SHA

are included in what I enabled with IIS Crypto. Yet still the server doesn't want to touch these cipher suites and allow a connection to be made. It just drops the connection instead, as evidenced by this attempt to connect using OpenSSL.

Why is IIS or Schannel not allowing the use of these cipher suites when, as far as I can tell, I have configured them both to use them regardless of the defaults?

can you connect to the IIS server using OpenSSL and one of those ciphers? `openssl.exe s_client -connect sitename:port -tls1 -cipher RC4-SHA` — Mass Nerder, Aug 04 '16 at 18:47
@MassNerder: Great idea. No, it acts the same way - [here's what I get](http://pastebin.com/Gb2Mgvvj). — Jesper, Aug 05 '16 at 10:55
If you can't connect with OpenSSL or the 2003 server it would suggest that your IIS server does not have the configured enabled to accept the connections. — Mass Nerder, Aug 05 '16 at 19:04

Mark · Answer 1 · 2017-10-12T23:13:37.010

I know this is old, but in case someone wants to know more, there are also locations within the registry for this. My thought is that perhaps TLS 1.0 is Enabled=0 or DisabledByDefault=1?

SSL / TSL:

Registry location: \HKey_Local_Machine\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols

If there are keys in the Protocols registry folder with sub keys of Client and Server, and DWORDS within them of DisabledByDefault and Enabled, then that is what is configuring it. The default state for Win 2012 (r1) was TLS1 was allowed and allowed by default. (If not, you can add them in)

(Note that Server is for incoming connections, and client for outbound.)

References:

Ciphers:

Registry location: \HKey_Local_Machine\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers

We used IIS Crypto too, after researching a lot, and finding that everyone just uses this program. (It freed us up from having a 1023 char limit on the Cipher Suite list in Group Policy Editor.)

(Aside: Win XP will loose all connectivity with HTTPS if 3DES (triple DES) gets culled)

References:

Thanks. I enabled TLS 1.0 on the DB server in the server folder and TLS 1.0 on the App server in the client folder and then the message went away — Lanklaas, Oct 12 '17 at 06:23
Glad to be of help :) Shame the "Gave up and changed entire platform" answer was what Jesper had to do. — Mark, Oct 12 '17 at 23:09
@Mark Agreed. Maybe the words in my answer are a little strong but the complexity of configuration compared to things changing wildly in updates without proper documentation add up to a really untenable situation. Nginx is only an application and doesn't have to deal with layered policies so it's an unfair comparison, but still, we are lucky people like you are around to help out or things would be even more unmanageable. The only reason I don't mark your answer as the answer is that it didn't solve *my* problem, but it's the most helpful one. — Jesper, Oct 24 '17 at 14:53
@Jesper, That's ok - don't feel you need to change the answer. I was a year later than you needed me. ;) Up voting is fine. There'll be other people out there like Lanklaas who'll get what they need from it. :) — Mark, Oct 26 '17 at 23:33

score 1 · Accepted Answer · answered Aug 08 '16 at 07:55

TL;DR: Gave up and used Linux and Nginx.

I never found the answer to what was missing. Beyond the Windows Server 2012 R2 server mentioned, I set up a Windows Server 2008 R2 server and fully updated that and used IIS Crypto in the same way, and it seems to me like there's been some sort of RC4 kill switch deployed in some update along the line that is unable to be deactivated in the documented way, especially because another Windows Server 2012 R2 server that has not been down for patching does not do the same thing.

Since I can't live in fear of running Windows Update, I had to resort to setting up an Ubuntu server running Nginx, handling TLS termination and reverse proxying to the server on plain HTTP on the server that now I didn't have to expose publicly. Microsoft's lack of exhaustive and accurate documentation and desire to dramatically change behavior in minor updates shows contempt for their customers and their businesses, and they would do well to look to their competitors for lessons on how to care about their customers' security while still trusting them with their own judgement.

score 0 · Answer 3 · answered Jan 23 '17 at 03:17

0

Most organisation will follow the IIS 8 hardening guidelines here: https://benchmarks.cisecurity.org/tools2/iis/CIS_Microsoft_IIS_8_Benchmark_v1.0.0.pdf

What I'd suggest you to check are the values defined here: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.NETFramework\v4.0.30319 SchUseStrongCrypto

Turning on Strong Crypto automatically disables RC4 support, and it's not something which the IIS Crypto tool touches.

answered Jan 23 '17 at 03:17

louis xie

125
1
5

This wasn't it for me (I turned it off) but will hopefully save someone else trying to accomplish this. – Jesper Jan 23 '17 at 11:44

IIS 8.5 server not accepting a TLS 1.0 connection from Windows Server 2003

3 Answers3

SSL / TSL:

Ciphers: