Stronger TLS validation for Cluster communication

[msft-paddy14]

Feature request type

enhancement

Is your feature request related to a problem? Please describe

For Garnet Cluster TLS mode, there's no remote cert validation if ClientCert required is set to false. Allowing all connections. However, during cluster gossip, this means a node from ClusterA(3 primaries) can connect to any node of ClusterB( 3 primaries) if a MEET is issued(keeps happening during gossip) using IP. Since IP reuse is common in K8s, it's possible for node to connect to some unwanted Cluster as the stale IP might not have been removed but might be valid as it's part of a different cluster. There seems to be an existing ClusterTlsClientTargetHost parameter in Garnet but it's not being used.
Currently, ClientCertRequired when set to false may be disabled for Clients to connect to server but it also prevents validation of internal nodes participating in gossip.

Describe the solution you'd like

Proposal is to use existing parameter ClusterTlsClientTargetHost to make the check stronger in ClientTlsAuthOptions by validating that remote cert (when Garnet acts as a client during Gossip) and local cert configured have same name along with existing checks. This will prevent nodes meant to be part of different cluster from communicating as part of gossip by failing TLS handshake. So that only MEET happens between nodes that are intended to part of cluster.

Sample error expected when different certs are configured for different nodes:

I don't think it should break existing scenarios since this should've always been the intended behavior and seems like we already had parameter but lacking validation.

Describe alternatives you've considered

No response

Additional context

No response