Conscrypt + Windows + Java-8 for TLS example with Self-signed cert

200 views
Skip to first unread message

Geoff Groos

unread,
May 8, 2019, 2:44:39 PM5/8/19
to grpc.io
Hello everyone,

I'm looking to implement the java-tls example on windows with kotlin. Specifically I'm only looking for server-side auth, skipping client side auth for now.

The end-goal is to have a java-server speaking to a dotnet client, but I'm starting with two JVM wrappers because the java-GRPC client on conscrypt seems to produce substantially better SSL errors than the C#/native client does.

So to do this I want to: starting from grpc java example-tls as a basis:

1. port their self-signed cert generator to a windows powershell script
2. create a netty server in the same vein
3. create a client in the same vein
4. start a GRPC service on the former and call it from the latter

I made a number of modifications in steps 1 and 2 because:
1. I didnt think it was reasonable for client-side code to mention netty. Why do I need bits of a webserver to connect to a GRPC channel?
2. I'm not exactly sure how native deps + service locators play into the server, but netty fails to load native dependencies when I use SecurityGrpcSslContexts.configure(it, SslProvider.OPENSSL) with netty shaded on my java8 + win10 machine. So I went with netty on conscrypt, which works in insecure mode. Is this a big problem?

At first I was receiving subject name problems, but I solved (unsafely?) that problem by changing the `hostnameVerifier` to simply allow 127.0.0.1 as the hostname
- this is almost certainly not what I want to do. I was hoping their was a simple `allowSelfSignedCerts = true` I could plop into a configuration somewhere, but I couldn't find it.
- given that I will need to do this same thing with the C# client which, IIRC, relies on the windows SSL API's, what is a general strategy here?

Now I've got CA chain checking troubles:

Caused by: java.security.cert.CertificateException: java.security.cert.CertPathValidatorException: Trust anchor for certification path not found.
    at org
.conscrypt.TrustManagerImpl.verifyChain(TrustManagerImpl.java:660)
    at org
.conscrypt.TrustManagerImpl.checkTrustedRecursive(TrustManagerImpl.java:537)
    at org
.conscrypt.TrustManagerImpl.checkTrusted(TrustManagerImpl.java:493)
    at org
.conscrypt.TrustManagerImpl.checkTrusted(TrustManagerImpl.java:412)
    at org
.conscrypt.TrustManagerImpl.getTrustedChainForServer(TrustManagerImpl.java:356)

and I've never properly understood when and where the chain is important and how you bundle it with the initial cert. I thought that the above script was attempting to allow for this by providing `ca.crt` as a "root" cert and `server.crt` as a "leaf" cert, and that by shipping ca.crt this problem would go away. But here it is.

Is there a problem with the port of the cert generator?
Is there something I'm missing in conscrypt and will subsequently be missing in the C# client?
Is there a way I can get client-side openSSL validation without use of netty?

Thanks for any help.

---

As a quick aside: Despite my relatively low knowledge of SSL I am aware of the problems with self-signed certs. Where possibly I plan on using a real cert that exists in trust stores, but in two use cases (the first being debugging locally) I will need self-signed certs.

chengyu...@google.com

unread,
May 21, 2019, 4:19:43 PM5/21/19
to grpc.io
There are some problems with the grpc java example-tls, especially for generating the certs. We fixed the example recently (checkout example-tls on master branch), while the script for generating certs in the README might still not give you the correct certs (it's missing some config for Subject Alternative Names). Please look at this PR for more details.
Reply all
Reply to author
Forward
0 new messages