TLS client validates against wrong hostname, breaks per-node certificates

[Aaronontheweb]

Problem

TLS client-side validation uses the wrong hostname. In DotNettyTransport.cs line 355:

var host = certificate.GetNameInfo(X509NameType.DnsName, false);  // BUG: Uses CLIENT's cert
tlsHandler = TlsHandler.Client(host, certificate);

This extracts the DNS name from the client's own certificate instead of using the remote server's address. Result: RemoteCertificateNameMismatch errors when using distinct per-node certificates.

Example

• Client A has cert with CN=node-a.example.com
• Client A connects to Server B at node-b.example.com
• Client A expects server cert to match node-a.example.com ❌
• Validation fails even though both certs are valid

Fix

var host = remoteAddress.Host;  // Use the address we're connecting TO

Additional: Configuration Option Needed

Even with the fix, hostname validation breaks legitimate mutual TLS scenarios:

• IP-based connections (10.0.0.1 vs cert has DNS:node1.example.com)
• Service discovery (dynamic addresses)
• Per-node certificates in P2P clusters

Add configuration to disable hostname validation for mutual TLS:

akka.remote.dot-netty.tcp.ssl {
  validate-certificate-name = false  # Default for backward compat
}

When false: Validates cert chain against CA, ignores RemoteCertificateNameMismatch
When true: Traditional TLS hostname validation

Testing

Extend DotNettyMutualTlsSpec.cs:

• Different certs + validation disabled → Pass
• Different certs + validation enabled → Fail (name mismatch)
• Same cert + validation enabled → Pass
• Config unspecified → Pass (default disabled)

Acceptance Criteria

• Fix line 355 to use remoteAddress.Host
• Add validate-certificate-name config (default: false)
• Custom validation callback when disabled
• Test coverage for both modes
• Update docs

[Aaronontheweb]

validate-certificate-name = false # Default for backward compat

probably should be validate-certificate-hostname