Summary

When the Trillian gRPC address includes a dns:/// resolver scheme (used to enable client-side round_robin load balancing with headless Kubernetes Services), the dial() function passes the raw address, scheme included, into tls.Config.ServerName and the gRPC channel authority

This breaks TLS: the x509 certificate verification matches SANs against "dns" (the URI scheme) instead of the actual hostname, failing with:

x509: certificate is valid for trillian-logserver.ns.svc, not dns

The fix strips the dns:/// prefix into a cleanHostname for TLS ServerName and grpc.WithAuthority(), while preserving the full scheme in the grpc.NewClient target so the DNS resolver stays active

strings.TrimPrefix is a no-op when the prefix is absent, so callers passing plain hostnames are unaffected

Tested on an OpenShift cluster with internal TLS:

• before: every Trillian gRPC call fails with the x509 error above
• after: TLS handshake succeeds and round-robin load balancing works across all trillian-logserver pod IPs

Release Note

Fixed a bug where using the dns:/// gRPC resolver scheme in the Trillian server address caused TLS certificate verification to fail. The URI scheme was incorrectly used as the TLS ServerName instead of the actual hostname. This affected deployments using client-side gRPC load balancing (round_robin) with TLS enabled.

Documentation