ARR Support for TLS 1.2 on Windows 2012 R2 [Answered]RSS

9 replies

Last post Sep 11, 2016 02:42 AM by milope

  • ARR Support for TLS 1.2 on Windows 2012 R2

    Sep 01, 2016 08:16 PM|dms666|LINK

    On a WIndows 2012 R2 server, I cannot get ARR to work unless TLS 1.0 (or SSL) is enabled.

    From what I've gathered, on Windows 2008 R2, ARR only supported TLS 1.0 and SSLv3. Is that the same with 2012 R2?

    I cannot find anything defintiive on whether or not ARR on Windows 2012 R2 supports TLS 1.2. If there's no default support, can it be added with reg fixes?

    Thanks in advance.

  • Re: ARR Support for TLS 1.2 on Windows 2012 R2

    Sep 02, 2016 03:20 AM|Jean Sun|LINK

    Hi dms,

    Based on my understanding, "enabled by default" means the key doesn't have to exist for it to be turned on.  You only need to add the value if you want to disable it.

    If you want to disable it, you can find how to do it in the following link.

    https://technet.microsoft.com/en-us/library/dn786418(v=ws.11).aspx#BKMK_SchannelTR_TLS12

    And the IIS Crypto is a great tool for easily seeing what protocols and ciphers are enabled on your server.

    Best Regards,

    Jean

    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue.
    If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.
  • Rovastar Rovastar

    5458 Posts

    MVP

    Moderator

    Re: ARR Support for TLS 1.2 on Windows 2012 R2

    Sep 03, 2016 06:43 AM|Rovastar|LINK

    I don't know of any way. I think it is still the same as Windows 2008.

    Well by default at least. Maybe it is possible to have a rewrite rule that forces TLS 1.2 to the backend servers. I might have a look on my test rig at some point.

    Troubleshoot IIS in style
    https://www.leansentry.com/
  • Re: ARR Support for TLS 1.2 on Windows 2012 R2

    Sep 03, 2016 05:04 PM|milope|LINK


    Don't know if we are referring to ARR as a server (receiving the request), or ARR as a client (sending the request). Either way as a Server or as a Client, both rely on Schannel. The difference is that as a server, it will rely on the Server registry keys, as
    a client, it will rely on the client registry keys.

    If my memory does not fail me and things haven't changed, ARR uses WinHTTP. Aside from the Schannel registries, maybe the one specified here (https://support.microsoft.com/en-us/kb/3140245) can help? Also, make sure the backend server also has TLS 1.2 and 1.1 enabled as well.
  • Re: ARR Support for TLS 1.2 on Windows 2012 R2

    Sep 03, 2016 10:03 PM|dms666|LINK

    ARR is receiving client requests and forwarding to another server. It fails if TLS 1.0 or SSL3 are disabled.

    It was my understanding that the SCHANNEL registry settings do not apply to the ARR module, but only IIS itself (i.e., when serving web pages).

    The discussions on these two threats lead me to believe that 2008 R2 does not support ARR via TLS 1.2 regardless of the SCHANNEL registry changes. I have yet to find any authoritative source on this, however.

    http://serverfault.com/questions/738757/is-it-possible-to-configure-arr-to-make-tls-1-2-outgoing-connections-in-server-2

    http://forums.iis.net/t/1230178.aspx?ARR+on+server+2012+R2+And+TLS1+2

  • Re: ARR Support for TLS 1.2 on Windows 2012 R2

    Sep 04, 2016 01:22 AM|milope|LINK


    That basically means ARR is not exposing the WinHTTP functions to add the option to use TLS 1.1 and TLS 1.2. That being the case, you're stuck with at most TLS 1.0 if that's the case. I still believe WinHTTP should use SChannel to perform its cryptography, however if the client is not instructed to even try TLS 1.2, it won't matter what the registries have.

    I still recommend trying the registry key in this article: https://support.microsoft.com/en-us/kb/3140245 as it's a fairly recent update that alters the default for WinHTTP.
  • Re: ARR Support for TLS 1.2 on Windows 2012 R2

    Sep 08, 2016 12:55 PM|dms666|LINK

    We heard back from Microsoft support. They confirmed what we had already concluded (here's their response, verbatim):

    Application Request Routing (ARR) does not support TLS 1.2 on windows server 2008 R2. Our Product group is working on the same. But it is resolved on windows server 2012 R2.

    So if you have 2012 R2 server and ARR is still failing kindly open a new case with our IIS team and they will help you to troubleshoot the issue.

    Now our experience with IIS on Windows server 2012 R2 seemed to imply that TLS 1.0 was still required by ARR. However, further testing showed that it was a third-party client application that was connecting to IIS/ARR that required TLS 1.0 and ARR was, in fact, connecting to a back-end web server via TLS 1.2.

  • Rovastar Rovastar

    5458 Posts

    MVP

    Moderator

    Re: ARR Support for TLS 1.2 on Windows 2012 R2

    Sep 08, 2016 06:31 PM|Rovastar|LINK

    I must say milope reply of https://support.microsoft.com/en-us/kb/3140245 looked the most promising.

    The winhttp area that it looked like ARR was using could be up-gradable to use more secure TLS.

    Which makes it even more confusing by Microsoft's response - as page above is for with Windows 2008R2 also.

    Thanks for your reply though.

    I can see this question popping up more and more as TLS 1.0 get deprecated. Maybe I will have to do a little more digging myself.

    Troubleshoot IIS in style
    https://www.leansentry.com/
  • Re: ARR Support for TLS 1.2 on Windows 2012 R2

    Sep 09, 2016 11:21 AM|dms666|LINK

    I agree - why wouldn't Microsoft at least mention that KB, as it implies that 2008 R2 can be updated to allow ARR to use TLS 1.2.

    I can only guess that maybe ARR ignores or cannot use the TLS changes introduced by that KB.

  • Re: ARR Support for TLS 1.2 on Windows 2012 R2

    Sep 11, 2016 02:42 AM|milope|LINK

    It's really a thing of precedence. The KB above states that it changes the default behavior of WinHTTP. However any application-level flag will take precedence over the reg keys. Applications that use the default flags of WinHTTP will benefit from it, however.