Hi, Indeed the clients present certificates. The short question is: why when the server is set to GRPC_SSL_REQUEST_CLIENT_CERTIFICATE_BUT_DONT_VERIFY does it need the root cert? In this case it's specifically not verifying the client, so there is no point in needing it? Or am I missing something? What I would expect is both "case 1" and "case 3" above to work, b/c it should make no difference if the server has a root cert to check against in my setup.
Also this not consistent with eg gRPC-java(ie the prod client), they are working fine without the root cert(although ssl verification must obliviously be disabled b/c I am using self-signed certs). On Wednesday, December 12, 2018 at 7:39:04 AM UTC+1, [email protected] wrote: > > 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/20e05913-4042-4f4f-bde3-2a42abd7515e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
