Issue with System.Data.SqlClient.SqlException differences between Win/Mac Fx/Core

[odhanson]

Hi

We are facing an issue with difference in behavior between our Windows (based on FX) and Mac (based on .NET 5) implementation for connecting to SQL server. We are trying to make an encrypted connection to a server that doesn't support it.

In both environments we will receive a SqlException, but in windows, we receive -2146893019 as the Number of the error, and in Mac it is 0. We use this number to identify the specific exception (that the user is trying to connect to a non-secure server), but on Mac this is broken.

Is there a bug here in the .NET core implementation ? Is there an alternative way to get this done ?

Some more details.
In windows, we receive the following error message:
"{"A connection was successfully established with the server, but then an error occurred during the login process. (provider: SSL Provider, error: 0 - The certificate chain was issued by an authority that is not trusted.)"}"
ErrorCode: -2146232060
Source: ".Net SqlClient Data Provider"
Number: -2146893019
InnerException: {"The certificate chain was issued by an authority that is not trusted"} (System.Exception {System.ComponentModel.Win32Exception})

On Mac, we receive:
"A connection was successfully established with the server, but then an error occurred during the pre-login handshake. (provider: TCP Provider, error: 35 - An internal exception was caught)"
ErrorCode: -2146232060
Number: 0
InnerException: {System.Security.Authentication.AuthenticationException: The remote certificate was rejected by the provided RemoteCertificateValidationCallback. at System.Net.Security.SslStream.SendAuthResetSignal(ProtocolToken message, ExceptionDispatchInfo exception) at System.Net.Security.SslStream.ForceAuthenticationAsync[TIOAdapter](TIOAdapter adapter, Boolean receiveFirst, Byte[] reAuthenticationData, Boolean isApm) at System.Net.Security.SslStream.ProcessAuthentication(Boolean isAsync, Boolean isApm, CancellationToken cancellationToken) at System.Net.Security.SslStream.AuthenticateAsClient(SslClientAuthenticationOptions sslClientAuthenticationOptions) at System.Net.Security.SslStream.AuthenticateAsClient(String targetHost, X509CertificateCollection clientCertificates, SslProtocols enabledSslProtocols, Boolean checkCertificateRevocation) at System.Net.Security.SslStream.AuthenticateAsClient(String targetHost) at System.Data.SqlClient.SNI.SNITCPHandle.EnableSsl(UInt32 options)}
Source: Core .Net SqlClient Data Provider"

[Wraith2]

On windows can you set AppContext.SetSwitch("Switch.Microsoft.Data.SqlClient.UseManagedNetworkingOnWindows",true);; somewhere ( I usually do it in main) before you touch any sql classes and see if that changes the reporting of the error?

[odhanson]

@Wraith2 how will that help ? The problem is that the Mac version doesn't give me any indication I can use to detect that the authentication failed due to encryption not supported.

[Wraith2]

It'll let us see if the difference in error reporting is down to the network interface strategy and if it is then it can be replicated on windows with that switch which will make debugging much easier.

[odhanson]

@Wraith2 for windows, we are using .NET FX 4.0 (yeah I know... ) is there an alternative to the SetSwitch API ? (AppContext doesn't exist)

[Wraith2]

It should be present on netfx 4.6 and later according to https://apisof.net/catalog/a9bb54b0-2ca2-4d6b-9ee3-120c58aad192 and if you're on an earlier version of the runtime then this library might not be supported (depending on version, one of the MS team will know the details) because it requires netfx 4.6 or later.

[odhanson]

I see the mix up now. We are using System.Data.SqlClient (4.8.0). Its not part of this repo.

[Wraith2]

The Microsoft.Data.SqlClient version is derived from the system versions and has had a lot of perf and stability work done. It's well worth trying and if it exhibits the same behaviour it might be fixable. At this point the System versions are very unlikely to be updated for anything other than a major problem.

[odhanson]

Yes. I understand. But unfortunately, we have a hard requirement to support older .NET FX versions so we need to still use the System.Data namespace. I will try to refactor to conditionally use the new Microsoft.Data on Mac. Question would be if this issue is exhibited on Mac in the new implementation also. And in any case, I would not be able to help run with that AppContext switch indicated above, since in windows we will be using System.Data anyhow.

[odhanson]

So the good news, that switching to Microsoft.Data.SqlClient was super easy (just needed to conditionally reference different namespace and nuget). But the actual issue remains on Mac. We don't get an indication in the error number that can be used to understand that the reason for the connection failure, unlike native windows.

[johnnypham]

Hi @odhanson, it seems to be an issue with managed SNI as I'm able to reproduce it on Windows using the AppContext switch mentioned by Wraith. I'll look into it.

[odhanson]

@johnnypham thanks. Let me know if you need anything else.