Windows Server 2016 Standard 上的“无法创建 SSL/TLS 安全通道”——可能是 TLS 1.3 问题？

Question

I inherited a web app that acts as a corporate dashboard. It's an ASP.NET app. .NET version = 4.7.2 It's running on two Windows 2016 Standard servers running IIS 10. Been in operation for many years.

One of the things the app does is make an HTTP request to a particular https:// URL, grab the data, parse out the JSON, and cache the list of objects. This has been working for many, many months. (Note: the "remote" server we're calling is still "in-house". Another person within my team basically "owns" that.)

Well, on Thanksgiving Weekend, it looks like the Prod App Pool cycled. And immediately that query started erroring with "System.Net.WebException: The request was aborted: Could not create SSL/TLS secure channel."

Myself and a few other folks were paged. At the time, we didn't notice (in Event Viewer) that the App Pool had cycled. After a few hours of investigating (and rebooting the app servers), the fellow who "owns" the server we are querying quickly set up a new end point for that same resource...setting it to allow HTTP connections / not require the use of HTTPS. The intention was that this would be a work-around until we could investigate the problem later.

Well, it's now "later".

The remote server that we are calling appears to require the use of TLS 1.3. I confirmed this by using both Firefox and Chrome on my own laptop to pull up a couple of https: urls on that server.

So, Ah-ha, I thought to myself, I had found information earlier this afternoon suggesting that Windows Server 2016 Standard didn't support the use of TLS 1.3! ( https://learn.microsoft.com/en-us/windows/win32/secauthn/protocols-in-tls-ssl--schannel-ssp-#tls-protocol-version-support )

But then I remembered: Earlier, I had been able to pull up those https: URLs in Chrome while logged onto my app's webservers, Sure enough. I went over there and retested with Firefox and Chrome. Both said the connections they'd made were using TLS version 1.3 !!

So, what the???? That makes it seem like Windows Server 2016 Standard DOES support TLS 1.3???

And, from everything I've read, since my app is using .NET version 4.7.2, it should default to using whatever the default protocol for the OS is. So, shouldn't it too be using TLS 1.3? Why the heck can't it make a connection?

I'm certainly needing some direction on what to do next.

Thanks!

Answer 1

Background

Many statements from your question body above are true, but you need to put the contents into contexts so as to get the whole picture.

First, Chrome/Firefox supports TLS 1.3, but that support comes from the crypto libraries (many options out there, Mozilla NSS, OpenSSL and so on) they ship with themselves, not from Windows native crypto API.

Second, like you found out, Windows Server 2016 does not support TLS 1.3 natively because its underlying crypto API lacks of TLS 1.3 support. TLS 1.3 support is only included in Windows Server 2022 at this moment (and whether it will be back ported to previous Windows versions is unknown).

Third, when you try to analyze Windows components (like .NET Framework) or products, you need to identify what they rely on to perform TLS, Windows native crypto API or their own dependencies (like Chrome/Firefox does).

Answer to your specific ASP.NET question

Sadly it is well known that BCL classes in .NET Framework rely on Windows native crypto API, so on Windows Server 2016 you can go with TLS 1.2 at most.

If your application needs TLS 1.3 badly, you need to upgrade to Windows Server 2022, or switch to a third party crypto API.

Reference

• https://www.quora.com/How-does-one-decide-between-OpenSSL-GnuTLS-and-Mozillas-NSS
• TLS 1.2 on Windows Server 2003 and XP