I would like to understand your setting better. Does your client present a certificate? If client does not have a certificate, you could use GRPC_SSL_DONT_REQUEST_CLIENT_CERTIFICATE. When client presents a certificate to server, server needs to verify the certificate that is chained back to root certificates. That is reason server needs CA's cert (as root pem) so that it could verify client certificate. So it is expected behavior.
Does this answer your question? On Wednesday, November 28, 2018 at 8:01:55 AM UTC-8, [email protected] wrote: > > Hi, > > I am currently putting in place an internal CA, and I have encountered an > issue with the SSL behavior. > > *## case 1 * > > - GetServerCredentials: pem_root_certs = ""; > - GetClientSslCredentials: ssl_opts.pem_root_certs = > ca_cert; > > > *-> GetPeerIdentity empty: call fails*expected result: should work > > *## case 2* > > - GetServerCredentials: ssl_opts.pem_root_certs = ca_cert; > - GetClientSslCredentials: ssl_opts.pem_root_certs = ""; > > > *-> "Handshake failed with fatal error SSL_ERROR_SSL: error:1416F086:SSL > routines:tls_process_server_certificate:certificate verify failed"Logical: > server's cert is not trusted by the client* > expected result: logical b/c server's cert if not trusted by the system > > *## case 3* > > NOTE: this is the "standard case" > > - GetServerCredentials: ssl_opts.pem_root_certs = ca_cert; > - GetClientSslCredentials: ssl_opts.pem_root_certs = > ca_cert; > > *-> Ok [GetPeerIdentity returns the client's cert]* > > *## case 4* > > - GetServerCredentials: ssl_opts.pem_root_certs = FAKE_ca_cert; > - GetClientSslCredentials: ssl_opts.pem_root_certs = > ca_cert; > > > > > > > > > > > > > *-> I1128 16:45:54.518586236 8769 subchannel.cc:656] New > connected subchannel at 0x60400001d550 for subchannel 0x616000031280E1128 > 16:45:54.518711293 8789 ssl_transport_security.cc:472] Corruption > detected.E1128 16:45:54.518737349 8789 ssl_transport_security.cc:448] > error:0407008A:rsa routines:RSA_padding_check_PKCS1_type_1:invalid > paddingE1128 16:45:54.518749675 8789 ssl_transport_security.cc:448] > error:04067072:rsa routines:rsa_ossl_public_decrypt:padding check > failedE1128 16:45:54.518760139 8789 ssl_transport_security.cc:448] > error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP libE1128 > 16:45:54.518768124 8789 secure_endpoint.cc:181] Decryption error: > TSI_DATA_CORRUPTEDD1128 16:45:54.519019924 8769 > dns_resolver.cc:259] In cooldown from last resolution (from 13 ms > ago). Will resolve again in 987 > ms../tests/test_route_device_autolink.cpp:79: FailureValue of: res.ok() > Actual: falseExpected: true* > > My question is: why does the server need to have the CA's crt? > It makes sense that it needs to be present on the client when using a > self-signed server cert(or any non system-trusted ones). > > Is this a bug or the expected behavior? > > My problem is that I am using(or trying to use) cfssl as CA, and I would > rather avoid copying around the root crt(even if its not at all a security > issue). > That is because cfssl API does not allow me to access the CA's .crt, so it > would have to copy it out-of-band. > > NOTE: it could be related to https://github.com/grpc/grpc/issues/12146 > > -- 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 post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/grpc-io. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/f12ec6b6-2a60-43f1-8e1c-47d6a71b51e7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
