Most likely because the TLS handshake fails before the gRPC application-level communication can even begin, Netty cannot establish a valid HTTP/2 connection. This failure is then reported up to the gRPC layer as a generic UNKOWN status.

When useTransportSecurity() is called without further configuration, gRPC-Java (via Netty) will try to establish a TLS connection using the system's default trust store. The connection is likely failing during the TLS handshake. Take a look for — server is not configured for TLS on that port or server's certificate is not trusted by the client's default trust store. Perhaps the server is using a self-signed certificate, or a certificate from a custom Certificate Authority (CA) that isn't in the client's default trust store?

If this doesn't let us debug then enable gRPC's verbose to get more detailed logs from the underlying Netty transport.