Repository navigation
investigate TLS13 on MacOS #1979
Description
It seems like on Catalina TLS1.3 works out of the box - at least with Safari.
However, when I try to use in .NET I get the following error:
System.Net.Http.HttpRequestException: The SSL connection could not be established, see inner exception.
---> System.Security.Authentication.AuthenticationException: Authentication failed, see inner exception.
---> Interop+AppleCrypto+SslException: bad protocol version
--- End of inner exception stack trace ---
This may be because API we currently use is marked as obsolete or there may be something missing since TLS1.3 support got out before Catalina. And all TLS1.3 tests are disabled on all versions of MacOS.
related to #1720
Reacted by Igor Benić, Ricardo Boss, Will-Low, Karim Besbes, Burak Berk, Jose , tina-hello, Ján Bočínec, Jeremy Schneider, Daniel Wegener and 4 more
Reacted by Igor Stipetić, Kris Pypen, Ján Bočínec and Jeremy Schneider
Activity
wfurt commentedon May 26, 2020
It seems like we will need to rewrite PAL to use new Network framework API.
That should fix iOS as well.
https://mailarchive.ietf.org/arch/msg/tls/5QjzTilqjomSyzENtgfaAqQOhbA/
karelz commentedon Jun 18, 2020
Triage: Will require PAL rewrite on Mac -- out of scope of 5.0.
The new Catalina API will help also iOS and light up TLS 1.3 there.
chucker commentedon Mar 24, 2022
Is this still current? In a .NET 6 console app with macOS 12.3 against a host that only seems to support TLS 1.3, I still get the same stacktrace as above. .NET info:
Details
.NET SDK (reflecting any global.json): Version: 6.0.201 Commit: ef40e6aa06Runtime Environment:
OS Name: Mac OS X
OS Version: 12.3
OS Platform: Darwin
RID: osx.12-x64
Base Path: /usr/local/share/dotnet/sdk/6.0.201/
Host (useful for support):
Version: 6.0.3
Commit: c24d9a9
.NET SDKs installed:
6.0.201 [/usr/local/share/dotnet/sdk]
.NET runtimes installed:
Microsoft.AspNetCore.App 6.0.3 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 6.0.3 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
wfurt commentedon Mar 24, 2022
yes, it is @chucker. #27727 has more detail but it is essentially same work. It is not clear at this moment if it is even feasible.
bhoffman-splunk commentedon May 5, 2022
Not to add pressure, but I am more and more encountering TLS 1.3-only systems. This is especially true for internal, greenfield APIs that companies build, since they can "start secure" from the beginning. Any work around (such leveraging OpenSSL as is done in Linux) would be tremendously helpful.
wfurt commentedon May 5, 2022
Is there need for client, server or both? I was thinking about some fallback because to allow HTTP2 for macOS developers (#27727) We generally do that for HTTP3/Quic (preview in 6.0) so we have some parts already in a place. if we go down this path, it would probably be opt-in feature with dependency on OpenSSL from Brew/MacPorts. Would that be acceptable?
chucker commentedon May 5, 2022
@wfurt client in my case. macOS as a server is uncommon. But server might still be useful (if less important) for developers who run Kestrel on a Mac?
62 remaining items
wfurt commentedon Nov 14, 2025
I don't see anything obvious. Client offered several versions and server picked 1.2 with some EC suite. Then it has some exchange and it dies. We will probably need to set up some repro. I don't think we have done any testing with SQL. There is another layer of complexity where the TLS frames are chipped and embedded inside TDS.
fhenriquezn commentedon Dec 4, 2025
Hey guys, I am experiencing the same TLS protocol error on .NET 10 with macOS Tahoe (26.1) on Apple M4 Max. When running
dotnet restore --verbosity detailed, it fails with:The SSL connection could not be established...
Authentication failed...
bad protocol version
I've already tried
dotnet dev-certs https --trustand clearing local certificates, but the issue persists. Is there a specific workaround or fix for this environment?wfurt commentedon Dec 4, 2025
Are you restoring from some private server or is it reachable publicly @fhenriquezn? @liveans has repro for the SQL case above and he is trying to figure it out.
fhenriquezn commentedon Dec 5, 2025
@wfurt Yes, it's a private server. It's behind Cloudflare. I had the "Minimum TLS Version" setting configured to 1.3 in the Cloudflare dashboard (SSL/TLS → Edge Certificates).
Changing it back to 1.2 allowed dotnet restore to succeed immediately.
To clarify, my goal is to use TLS 1.3. I was under the impression that native support (which wasn't slated for .NET 9) would arrive with .NET 10, but that doesn't seem to be fully the case yet.
wfurt commentedon Dec 5, 2025
It is not enabled by default @fhenriquezn. See #1979 (comment)
Current goal is to flip the switch in 11.0 if we can resolve reported issues.
fhenriquezn commentedon Dec 5, 2025
Yes, but that will only partially solve it. That configuration may work for the running application, but not for CLI commands like
dotnet restore—am I correct?wfurt commentedon Dec 5, 2025
Using
DOTNET_SYSTEM_NET_SECURITY_USENETWORKFRAMEWORK=1environment should work of any tool.fhenriquezn commentedon Dec 5, 2025
That worked, thank you very much :)
wfurt commentedon Dec 5, 2025
Just to be sure: you set the MinTLS back to 1.3 and everything is good so far, right?
fhenriquezn commentedon Dec 5, 2025
Yes sir
nano ~/.zshrc1.2. add
export DOTNET_SYSTEM_NET_SECURITY_USENETWORKFRAMEWORK=1then save