Score:0

Windows Server 2012 R2 TLS 1.2 Issue

cn flag

I am facing issues with TLS 1.2 on my Windows Server 2012 R2 (application web server,IIS), where I am unable to access https://api.nuget.org/v3/index.json via Internet Explorer even after I see that TLS 1.2 has been enabled.

I have another server with the same OS and same OS updates (but no IIS) and this server has no problem accessing the API or any other endpoint with TLS 1.2)

On the problematic server, I've tried the following:

  1. Used IISCrypto to enable everything -> Restart -> FAILED
  2. Manually Change Registry settings following Microsoft documentation - https://docs.microsoft.com/en-us/mem/configmgr/core/plan-design/security/enable-tls-1-2 - FAILED
  3. Used the following Script to completely reset and re-enable only TLS 1.2 - https://www.hass.de/content/setup-microsoft-windows-or-iis-ssl-perfect-forward-secrecy-and-tls-12 - FAILED

At this time, I've spent the better of 3 days trying to troubleshoot and see what the issue is between these two servers, why one windows server works and another doesn't.

Any tips, troubleshooting steps or tools would be most welcome!

Screenshots enter image description here

  • via Nuget CLR
  • on the problematic server enter image description here
  • On the server that works enter image description here
in flag
Even enabling TLS 1.2 does not help you because Windows 2012 R2 does not support the ciphers API.nuget.org supports. The API server requires [RSA based ciphers](https://www.ssllabs.com/ssltest/analyze.html?d=api.nuget.org&s=2620%3a1ec%3a46%3a0%3a0%3a0%3a0%3a69) and those are simply not present and thus can not be enabled https://docs.microsoft.com/en-us/answers/questions/227738/windows-server-2012-r2-tls-12-cipher-suites.html
cn flag
@Robert, like I stated, I have another server which is also on Windows 2012 R2 API is accessible on that, how is that possible if it is an unsupported cipher issue? this is the reason I am so confused and lost, works on one server and not on another
cn flag
I don't see where this is related to TLS 1.2.
cn flag
@GregAskew see the screenshot from IE (2nd screenshot)
Score:0
cn flag

So, After hours of troubleshooting I was finally able to resolve the issue and get the API accessible from our server over TLS 1.2.

We have .net framework on our server which was having trouble accessing the API. Microsoft recommends we set the following registry to force SystemDefaultTlsVersions

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v2.0.50727]
"SystemDefaultTlsVersions"=dword:00000001
"SchUseStrongCrypto"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319]
"SystemDefaultTlsVersions"=dword:00000001
"SchUseStrongCrypto"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727]
"SystemDefaultTlsVersions"=dword:00000001
"SchUseStrongCrypto"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
"SystemDefaultTlsVersions"=dword:00000001
"SchUseStrongCrypto"=dword:00000001
Score:0
se flag

My Reputation ist top low so I have to write an answer.

The browsers message may be misleading

You should validate If the DNS resolves the same target and if the client detects any kind of proxy.

Them may be a packet inspection by firewall maybe with transparent proxy.

Validate what response you get with s_client in openssl: https://stackoverflow.com/questions/7885785/using-openssl-to-get-the-certificate-from-a-server

Use DeveloperTools in browser to take a Look at "Network" and see where your request was sent (maybe through proxy) and what response you got.

Disable some SSL/TLS checks in Powershell: https://stackoverflow.com/questions/34331206/ignore-ssl-warning-with-powershell-downloadstring

Validate both have same Network config regarding IPv6. Maybe one of them connects to another server because of that.

EDIT: at least do the openssl check to be sure that you can get the correct certificate. Disable SSL/TLS Check for Powershell and testing would help either to be sure about the problem.

cn flag
both the servers are in a DMZ and the only difference between them is one is running IIS and another isn't
se flag
That should not be the reason as I can'treproduce your problem in other environments. Firewall policies may be different for the servers.
cn flag
I've asked the server team to check the firewall policies between the servers.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.