GRPC C-Core clients can connect to .NET Core server built on Linux, but not on Windows

I’ve already asked this question on StackOverflow, but I thought I’d repost it here.

I’m trying to get a GRPC server (written in .NET core) and client (written in C++) to communicate over a SSL/TLS-secured channel.

The server targets “netcoreapp3.1”, and depends on “Grpc.AspNetCore” version 2.28.0. The server code itself is basically copied from some simple online examples. The Startup.cs and Program.cs are not too interesting on their own & probably aren’t the problems, so I just uploaded them to a gist (do note the call to UseHttps though). Everything builds, and I know that it works because I wrote a .NET core GRPC client which connects over HTTPS just fine (sources for that here, also very simple).

Unfortunately, I need to be using a C++ client to make the connection. Theoretically, the process is simple: get the .pfx file corresponding to the certificate passed to the UseHttps call, use it to create a server.crt via openssl, and use that to create a secure channel for the C++ client like so:

grpc::SslCredentialsOptions sslOpts{};
sslOpts.pem_root_certs = file_to_string(path_to_server_crt);
auto creds = grpc::SslCredentials(sslOpts);
auto channel = grpc::CreateChannel("localhost:50052", creds);

I’ve used the client successfully with a C++ grpc server, so there’s no lingering bugs on that side either. When I point it at my .NET core server though, things break. The client side info isn’t interesting, just a GRPC error 14. When the server is set to log things at Trace though, something pops out

dbug: Microsoft.AspNetCore.Server.Kestrel.Core.KestrelServer[2] 
  Connection id "0HM6UG4PBICBP" accepted.
dbug: Microsoft.AspNetCore.Server.Kestrel[1]
      Connection id "0HM6UG4PBICBP" started.
dbug: Microsoft.AspNetCore.Server.Kestrel.Https.Internal.HttpsConnectionMiddleware[1]
      Failed to authenticate HTTPS connection.
System.Security.Authentication.AuthenticationException: Authentication failed, see inner exception.
---> System.ComponentModel.Win32Exception (0x80090367): No common application protocol exists between the client and the server. Application protocol negotiation failed.
--- End of inner exception stack trace ---
// Some detailed stack trace, pretty sure it's garbage
dbug: Microsoft.AspNetCore.Server.Kestrel[2]
    Connection id "0HM6UG4PBICBP" stopped.
dbug: Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets[7]
    Connection id "0HM6UG4PBICBP" sending FIN because: "The Socket transport's send loop completed gracefully

No common application protocol exists between the client and the server, that’s certainly interesting: the server must be rejecting whatever protocol the C++ client is trying to use? What’s the solution to this problem?

Note: I should mention that the C++ client is being compiled/run from WSL 1 (Ubuntu 18.04) whereas the server is being run on Windows Server 2019 Datacenter.

EDIT: Just bumped the app to target netcore5.0 and use Grpc.AspNetCore version 2.3.5 and tried again. Nothing changes on the server side, but the client now prints the following error. I don’t think it reveals anything new, but I thought I’d add it

 E0303 14:28:14.976078900    1126 ssl_transport_security.cc:1458] Handshake failed with fatal error SSL_ERROR_SSL: error:10000410:SSL routines:OPENSSL_internal:SSLV3_ALERT_HANDSHAKE_FAILURE.

The stack trace I describe as “garbage” earlier also gets quite a bit shorter, becoming

     at System.Net.Security.SslStream.ForceAuthenticationAsync[TIOAdapter](TIOAdapter adapter, Boolean receiveFirst, Byte[] reAuthenticationData, Boolean isApm)
     at Microsoft.AspNetCore.Server.Kestrel.Https.Internal.HttpsConnectionMiddleware.OnConnectionAsync(ConnectionContext context)

[anlsh]

Just a final update: I set a repro repo earlier this week, and was unable to reproduce the issue on other machines. Whatever the issue was, it appears to have been some sort of misconfiguration on my end

[JamesNK]

@anlsh Create an issue at the link above and reference this issue.

Whatever the cause is here, it isn’t related to the Grpc.AspNetCore. The cause is lower-level in Kestrel’s TLS support.