Nathan, On server side, you can use the following to get the client' certificate
std::vector<grpc::string_ref> cert_list = server_context.auth_context().FindPropertyValues(GRPC_X509_PEM_CERT_PROPERTY_NAME); Thanks, Jiangtao On Wed, Dec 12, 2018 at 10:28 AM Jiangtao Li <[email protected]> wrote: > 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_hSpmG_FoQd%2BvzKExTRyi8Je99BN3Vows0ROjdG1b3%2BKw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
