In this example https://github.com/grpc/grpc-java/blob/master/interop-testing/src/test/java/io/grpc/testing/integration/TlsTest.java you see that the TLS client connection has various TLS parameters such as
.negotiationType(NegotiationType.TLS)
.sslContext(sslContext)
But my app has thus far used https://github.com/grpc/grpc-java/blob/master/core/src/main/java/io/grpc/ManagedChannelBuilder.java which by default seems to support TLS. The only parameter it takes is “usePlaintext” which can turn off TLS.
Note: I have installed OpenSSL on the machine, as recommended by https://grpc.io/docs/guides/auth.html
This page does state:
If the issuing certificate authority is not known to the client then a properly configured SslContext or SSLSocketFactory should be provided to the NettyChannelBuilder or OkHttpChannelBuilder, respectively.
So perhaps you can only use ManagedChannelBuilder when the issuing ca is known to the client… but I’m not sure what that means. Perhaps it means the cacert is on the jvm’s keystore?
Why do I not have to specify TLS parameters on a Managed channel builder?
Advertisement
Answer
Update: Since grpc-java v1.37.0, TlsChannelCredentials and TlsServerCredentials provide options necessary for configuring TLS in the majority of circumstances, such that only rarely should the transport-specific APIs be necessary. Since TlsChannelCredentials and TlsServerCredentials are stable APIs and can be used with the stable ManagedChannelBuilder API, they should be preferred over the unstable transport-specific APIs.
TLS configuration is complex and dependent on the implementation, and ManagedChannelBuilder can be used with things other than TLS. Thus, ManagedChannelBuilder only has coarse configuration of TLS (on/off). This works well in the common web browser TLS situation of 1) no client certificate and 2) the server certificate is signed by a CA that chains to a root CA in the client’s trust store.
However, there is more specific configuration available on NettyChannelBuilder and OkHttpChannelBuilder. How to configure TLS is different for each, because the implementation is different. The sslContext from your first code snippet is a Netty object; that obviously would be poor configuration in OkHttpChannelBuilder.
ManagedChannelBuilder isn’t supposed to have “all the options.” It’s supposed to have common options that exist across the transport implementations. More specific options are available on the specific transport implementation builders like NettyChannelBuilder and OkHttpChannelBuilder.