Thanks Jan for a quick replay. Right, there is no need for seting DefaultAuthority, it was just a leftover from some comment I found online.
Verifying the certificates using openssl was all good (the right format, able to read all the info, cert/key matching was good). Pay attention that I do not have CA cert, I am using one and only self-signed cert (and its private key) on server side, client side, and as a CA cert. Something like these guys here [https://github.com/sandtable/ssl_grpc_example]. Tracing seems to be not yet implemented for Windows, but I will give it a try with setting the proper verbosity (debug). On Tuesday, June 11, 2019 at 10:00:33 AM UTC+2, Jan Tattermusch wrote: > > 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/ecdfa2ed-fdf3-4e8f-a683-7177c8e4dbe1%40googlegroups.com.
