Setting new ChannelOption(ChannelOptions.DefaultAuthority, 
"SUBJECT_STRING") seems unnecessary. It's fine to use ChannelOptions.
SslTargetNameOverride but only for testing (do not use in production!).

Have you tried setting GRPC_VERBOSITY=debug and perhaps some traces (see 
https://github.com/grpc/grpc/blob/master/TROUBLESHOOTING.md)?

You can use openssl command line tools to verify that the certificates are 
well formed and that the server/client pem can be verified using the CA 
cert.

A working mTLS example for C# is here: 
https://github.com/jtattermusch/grpc-authentication-kubernetes-examples

On Monday, June 10, 2019 at 4:32:18 PM UTC+2, [email protected] wrote:
>
> Hi everyone!
>
> I have a self-signed certificate (with its private key as well), provided 
> on both server and client sides, and I want to use that certificate to 
> encrypt the connection in a mutual TLS way. Here is the code overview.
>
> // Getting the cert and PEM formats...
> byte[] certBytes = ReadCertificateBytes(...);
> X509Certificate2 cert = new X509Certificate2(secretBytes, string.Empty, 
> X509KeyStorageFlags.Exportable);
>
> string certPEMFormat = "-----BEGIN CERTIFICATE-----\n";
> certPEMFormat += 
> Convert.ToBase64String(containerCert.Export(X509ContentType.Cert), 
> Base64FormattingOptions.InsertLineBreaks);
> certPEMFormat += "\n-----END CERTIFICATE-----";
>
> string privateKeyPEMFormat = "-----BEGIN RSA PRIVATE KEY-----\n";
> privateKeyPEMFormat += ConvertPrivateKeyToPEM(cert);
> privateKeyPEMFormat = "-----END RSA PRIVATE KEY-----\n";
>
> var keypair = new KeyCertificatePair(certPEMFormat, privateKeyPEMFormat);
>
> // Client side
> SslCredentials clientCredentials = new SslCredentials(certPEMFormat, 
> keypair);
> var channel = new Channel(grpcEndpoint, channelCredentials);
>
> ...
>
> // Server side
> SslServerCredentials serverCredentials = new SslServerCredentials(new[] { 
> keypair }, certPEMFormat, false);
> Server server = new Server(someChannelOptions)
> {
>    // Create the default implementation
>    Services = { 
> ProtocolTypes.ExecutionService.BindService(executionServiceImp) },
>    // Using 0.0.0.0 to hear on all interfaces
>    Ports = { new ServerPort("0.0.0.0", port, serverCredentials) },
> };
> server.Start();
>
> By setting things like this, these are the errors I get.
>
> On client side:
> E0610 15:34:42.670602 0 ..\..\src\core\tsi\ssl_transport_security.cc:1229: 
> Handshake failed with fatal error SSL_ERROR_SSL: error:1000007d:SSL 
> routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED.
> On server side:
> E0610 15:34:42.076880 0 
> ..\..\src\core\tsi\ssl_transport_security.cc:1566: No match found for 
> server name: SERVERNAME.
>
> Looking around, I found an advice to pass these options to client's 
> channel (override target name, so it matches the Subject field from X509 
> certificate)
> // Client side
> var channelOptions = new List<ChannelOption>()
> {
>     new ChannelOption(ChannelOptions.SslTargetNameOverride, 
> "SUBJECT_STRING"),
>     new ChannelOption(ChannelOptions.DefaultAuthority, "SUBJECT_STRING")
> };
> var channel = new Channel(grpcEndpoint, channelCredentials, 
> channelOptions);
>
> And now, there are no error printings on the server side ('No match found 
> for server name'), but they still exist on the client side 
> (CERTIFICATE_VERIFY_FAILED).
>
> Certificate is already generated and provided so I can not change it. I 
> really tried with different arguments, options, combinations, and what not, 
> but I just can not establish this secure connection. Am I missing something 
> crucial here, can I use one and only self-signed certificate with private 
> key for mTLS (without any CA root certs), or maybe I am missing some flag 
> here or something minor?
>
> Thanks,
> Ugi
>

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/512ab5e1-9ad0-497b-abfb-856fa4b54c4a%40googlegroups.com.

Reply via email to