SSL Handshake issue on macOS Big Sur

Simply running this line of code that uses a DbContext with a SSL connection would result in this error.

using (var scope =
                app.ApplicationServices.GetRequiredService<IServiceScopeFactory>().CreateScope())
            using (var context = scope.ServiceProvider.GetService<DbContext>())
            {
                context?.Database.Migrate();
            }

Application startup exception: Npgsql.NpgsqlException (0x80004005): Exception while performing SSL handshake
 ---> System.Security.Authentication.AuthenticationException: Authentication failed, see inner exception.
 ---> Interop+AppleCrypto+SslException: Internal error
   --- End of inner exception stack trace ---
   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 Npgsql.NpgsqlConnector.RawOpen(NpgsqlTimeout timeout, Boolean async, CancellationToken cancellationToken)
   at Npgsql.NpgsqlConnector.RawOpen(NpgsqlTimeout timeout, Boolean async, CancellationToken cancellationToken)
   at Npgsql.NpgsqlConnector.Open(NpgsqlTimeout timeout, Boolean async, CancellationToken cancellationToken)
   at Npgsql.NpgsqlConnection.<>c__DisplayClass41_0.<<Open>g__OpenAsync|0>d.MoveNext()
--- End of stack trace from previous location ---
   at Npgsql.NpgsqlConnection.Open()
   at Npgsql.EntityFrameworkCore.PostgreSQL.Storage.Internal.NpgsqlDatabaseCreator.Exists()
   at Microsoft.EntityFrameworkCore.Migrations.HistoryRepository.Exists()
   at Microsoft.EntityFrameworkCore.Migrations.Internal.Migrator.Migrate(String targetMigration)
   at Microsoft.EntityFrameworkCore.RelationalDatabaseFacadeExtensions.Migrate(DatabaseFacade databaseFacade)
   at Nozomi.HistoricalJanitor.Startup.Configure(IApplicationBuilder app, IWebHostEnvironment env) in /Users/xxxxxx/Projects/xxxxx/xxxxx.HistoricalJanitor/Startup.cs:line 120
   at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor, Boolean wrapExceptions)
   at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
   at Microsoft.AspNetCore.Hosting.ConfigureBuilder.Invoke(Object instance, IApplicationBuilder builder)
   at Microsoft.AspNetCore.Hosting.ConfigureBuilder.<>c__DisplayClass4_0.<Build>b__0(IApplicationBuilder builder)
   at Microsoft.AspNetCore.Hosting.ConventionBasedStartup.Configure(IApplicationBuilder app)
   at Microsoft.AspNetCore.HostFilteringStartupFilter.<>c__DisplayClass0_0.<Configure>b__0(IApplicationBuilder app)
   at Microsoft.AspNetCore.Hosting.WebHost.BuildApplication()

https://gist.github.com/nixxholas/80b16f82fe8f0e04676d2ffcfe7a7a25

Running these on localhost would work fine tho. But when the local server (mac) connects to a GCP SQL server that has SSL, it fails.

[roji]

Yeah, very likely. Another thing I’d try, would be to connect from macOS to GCP PG outside of Npgsql (e.g. just with libpq or the Java driver); the issue may be in macOS’s SSL implementation, or in GCP’s, or possibly in .NET’s wrapping for macOS… But not in Npgsql…

[roji]

@nixxholas thanks for flagging this - but it’s very likely to be some compatibility/setup issue between .NET SslStream, the mac SSL implementation, and possibly GCP. Npgsql doesn’t do any of its own SSL - it simply delegates that task to the standard .NET SslStream.

First, does the same error occur with Linux/Windows as the client? That would help focus attention on the right area.

Second, I’d produce a minimal code sample with Npgsql (no EF Core), to make it more minimal. Just trying to open a connection should produce the exact same error.

At that point we’d probably file this as a bug on https://github.com/dotnet/runtime.