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.
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.