Thanks for the info, Jingtao.
In case of interest to anyone in future, on Windows, something like the
following works for loading a certificate from the system store:
var certStore = new X509Store(StoreName.Root, StoreLocation.CurrentUser);
certStore.Open(OpenFlags.ReadOnly);
var caCert = certStore.Certificates.Find(X509FindType.FindBySubjectName,
"xxx.yyyy.zzz", true)[0];
var rootCertificates = string.Join(Environment.NewLine,
"-----BEGIN CERTIFICATE-----",
Convert.ToBase64String(caCert.RawData, Base64FormattingOptions.
InsertLineBreaks),
"-----END CERTIFICATE-----");
var channelCredentials = new SslCredentials(rootCertificates);
var channel = new Channel("xxx.yyyy.zzz", channelCredentials);
var client = new Greeter.GreeterClient(channel);
Hacky, but it works for now...
On Monday, 29 October 2018 22:53:32 UTC+1, Jiangtao Li wrote:
>
> Here are complexity and technical challenges of loading system root store
> on MacOS and Windows. On MacOS, keychain APIs cannot be easily accessed by
> grpc c core. On Windows, the initial system root store could be empty,
> which cause negative user experience. There are performance penalty as well.
> We can put these into feature requests, but we do not resource at this
> moment to implement in the near term.
>
> Thanks,
> Jiangtao
>
>
> On Mon, Oct 29, 2018 at 2:47 PM Mark Nuttall-Smith <[email protected]
> <javascript:>> wrote:
>
>> Hi,
>> Indeed I'm running these tests on Mac OS, but in reality the deployed
>> environment is Windows. Is the system trust store supported there?
>> Thanks
>>
>> On Mon, 29 Oct 2018, 22:43 jiangtao via grpc.io, <[email protected]
>> <javascript:>> wrote:
>>
>>> Which platform does your client run? Looks like MacOS.
>>>
>>> For Linux, we support read from grpc system root store. For MacOS, it is
>>> not support yet -- grpc only reads default root from root pem certificates
>>> shipped with grpc.
>>>
>>> However, there are a few other ways to load root certificates. E.g., you
>>> can pass root certificate file through env var
>>> "GRPC_DEFAULT_SSL_ROOTS_FILE_PATH". Or you can
>>> specify grpc_set_ssl_roots_override_callback().
>>>
>>> On Monday, October 29, 2018 at 2:02:41 PM UTC-7, Mark Nuttall-Smith
>>> wrote:
>>>>
>>>> Hi Lidi,
>>>>
>>>> Yep, that works too - eg. for the Python client:
>>>>
>>>> with open('ca.crt', 'rb') as f:
>>>> creds = grpc.ssl_channel_credentials(f.read())
>>>> channel = secure_channel(host, creds)
>>>>
>>>> Where ca.crt is the same certificate that I imported into the trust
>>>> store.
>>>>
>>>> However, I don't want to distribute the client certificate with the
>>>> application. In a corporate environment I'd expect a sysadmin to push the
>>>> corporate CA root certificate to the trust store... right?
>>>>
>>>> Cheers, Mark
>>>>
>>>> On Monday, 29 October 2018 20:43:59 UTC+1, [email protected] wrote:
>>>>>
>>>>> Hi Mark,
>>>>>
>>>>> Can you try to add the root certificates to the gRPC client, and see
>>>>> if the warning go away?
>>>>> API for client-side credentials:
>>>>> https://grpc.io/grpc/python/grpc.html#grpc.ssl_channel_credentials
>>>>>
>>>>> Lidi
>>>>>
>>>>> On Monday, October 29, 2018 at 12:25:28 PM UTC-7, Mark Nuttall-Smith
>>>>> wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I have a gRPC client (C# and Python) using client-side SSL which is
>>>>>> terminated in an Istio ingress gateway (envoy) before reaching the
>>>>>> service.
>>>>>>
>>>>>> When using a genuine certificate from LetsEncrypt everything works
>>>>>> fine.
>>>>>>
>>>>>> However, when the ingress gateway is configured with a self signed
>>>>>> SSL certificate, generated from a root CA which has been added to the
>>>>>> trust
>>>>>> store (keychain/cert-manager) on the client machine, the connection
>>>>>> fails:
>>>>>>
>>>>>> E1029 17:01:45.274918000 123145515409408
>>>>>>> ssl_transport_security.cc:1229] Handshake failed with fatal error
>>>>>>> SSL_ERROR_SSL: error:1000007d:SSL
>>>>>>> routines:OPENSSL_internal:CERTIFICATE_VERIFY_FAILED.
>>>>>>
>>>>>>
>>>>>> Chrome/curl etc will connect to the http services behind the same
>>>>>> ingress gateway without SSL warnings (given that the root CA certificate
>>>>>> has been added to the trust store).
>>>>>>
>>>>>> My question is: should gRPC also be using the trust store for
>>>>>> client-side SSL? If so, any ideas what I might be doing wrong.
>>>>>>
>>>>>> Thanks,
>>>>>> Mark
>>>>>>
>>>>>> --
>>> 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/xtSG6QGP640/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to
>>> [email protected] <javascript:>.
>>> To post to this group, send email to [email protected]
>>> <javascript:>.
>>> 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/2f088a10-21a4-459d-bf80-a749f120d22a%40googlegroups.com
>>>
>>> <https://groups.google.com/d/msgid/grpc-io/2f088a10-21a4-459d-bf80-a749f120d22a%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/7b238aab-e597-4b19-ae3d-cec4a7b10c3b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
