tls: ValidateAuthority must only use the leaf certificate for matching SANs

[arjan-bal]

I noticed that the authority override call option is validated by the Tls client creds in an unexpected way.

grpc-go/credentials/tls.go

Lines 57 to 67 in 50c6321

	func (t TLSInfo) ValidateAuthority(authority string) error {
	var errs []error
	for _, cert := range t.State.PeerCertificates {
	var err error
	if err = cert.VerifyHostname(authority); err == nil {
	return nil
	}
	errs = append(errs, err)
	}
	return fmt.Errorf("credentials: invalid authority %q: %v", authority, errors.Join(errs...))
	}

The code is iterating over the whole chain here. My understanding is that PeerCertificates[0] is the leaf, and that is the only certificate we should be checking the hostname against.

Validating against the rest of the chain seems to imply we accept a situation where the Authority header matches the name of an Intermediate CA, which doesn't seem right.

gRPC Java and C++ don't seem to validate the hostname from the HTTP2 authority header override against the TLS cert SANs at all.

[arjan-bal]

@gtcooke94 can you comment on whether this is a bug? Also, do you know why gRPC Java and C++ don't validate the authority override using the peer cert while gRPC Go does?

[gtcooke94]

Thanks for the catch! Taking a look, will get a fix in soon