I just ran helloworld greeter client and greeter server, where server side does not have any root pem. Server side uses GRPC_SSL_REQUEST_CLIENT_CERTIFICATE_BUT_DONT_VERIFY. Client presents its certificate to server. Client and server can talk. GetPeerIdentity() did not crash. I may need more details before I can reproduce.
On Wed, Dec 12, 2018 at 9:58 AM Jiangtao Li <[email protected]> wrote: > Nathan, > > If server side sets GRPC_SSL_REQUEST_CLIENT_CERTIFICATE_BUT_DONT_VERIFY, > then server does not need to set client's CA cert as root cert. > > On your case (1), did you see handshake succeed? Where did you see the > failure, during GetPeerIdentity? It may be a bug, let me reproduce. > > Thanks, > Jiangtao > > > On Wed, Dec 12, 2018 at 1:22 AM <[email protected]> wrote: > >> 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 a topic in the >> Google Groups "grpc.io" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/grpc-io/KukId711HTE/unsubscribe. >> To unsubscribe from this group and all its topics, 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 >> <https://groups.google.com/d/msgid/grpc-io/20e05913-4042-4f4f-bde3-2a42abd7515e%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > -- 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/CACcm8_irnvjWX25QqiW6JmXEUE0ccux0aVtFBuuDHX%3DAny7afw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
