Flag to skip hostname/SAN verification on outgoing peer TLS connections?

[prateekkohli21]

Question

--experimental-peer-skip-client-san-verification disables SAN checking on incoming peer connections (server side). Is there an
equivalent for the outgoing (client side)?

Use Case

We run cross-site etcd clusters where peers are behind LoadBalancers with dynamic IPs. These IPs aren't known at cert-generation time
and can change at runtime.

The incoming side is solved with --experimental-peer-skip-client-san-verification=true. But on the outgoing side, Go's TLS client
still verifies the remote peer's server cert SAN against the advertised peer URL, causing:

x509: certificate is valid for , not

Alternatives considered

• --peer-auto-tls: Loses CA-based trust entirely
• Pre-populating all LB IPs in SANs: Not feasible with dynamic IPs
• DNS-based peer URLs: Adds operational complexity and propagation delays

Environment

etcd v3.5.9 (also interested in v3.6.x)

Does this flag exist, or would you consider it?

[dlanov]

No equivalent flag exists today for the outgoing/client-side peer TLS dial — this is a genuine asymmetry in etcd's TLS peer configuration.

Why the gap exists

--experimental-peer-skip-client-san-verification patches the server-side TLS handshake — it hooks into Go's tls.Config.VerifyPeerCertificate to skip SAN checking on certs presented by incoming peer connections. The outgoing direction uses a standard Go tls.Dial with a tls.Config built from the peer cert/key/CA. There is no etcd flag that sets InsecureSkipVerify: true or a custom VerifyConnection on that outbound dialer.

Your options today

Option 1 — DNS-based peer URLs with a wildcard or fixed DNS name
This is the cleanest solution for LB-fronted peers. Configure the LB with a stable internal DNS name (e.g. peer-site-b.internal) and include that name as a SAN in the peer cert. The LB IP can change freely; the DNS name in the cert stays valid:
--initial-cluster peer0=https://peer-site-b.internal:2380

Your cert just needs DNS:peer-site-b.internal as a SAN — no IP SANs needed. DNS propagation delay is typically sub-second for internal resolvers and is operationally simpler than it sounds.

Option 2 — Wildcard IP SAN via internal CA
If you control your CA (e.g. cert-manager, Vault PKI), issue peer certs with IP SANs covering your LB CIDR range. Not feasible with a public CA but entirely workable with an internal one:
subjectAltName = IP:10.0.0.0/8 # not valid in x509

Unfortunately x509 does not support CIDR SANs — you'd need to list individual IPs, which you said isn't feasible. Skip this.

Option 3 — Custom VerifyConnection via a fork/patch

etcd's peer transport is built in server/etcdserver/api/rafthttp/transport.go. The outbound dialer's tls.Config could be patched to use a VerifyConnection func that skips ServerName matching but still validates the cert chain against your CA — giving you CA trust without SAN enforcement. This is roughly what --experimental-peer-skip-client-san-verification does on the inbound side. A PR adding --experimental-peer-skip-server-san-verification (or similar) mirroring the existing flag would be a reasonable contribution.

Recommendation

For your use case, Option 1 (DNS peer URLs) is the right path. The operational complexity of internal DNS is lower than maintaining dynamic IP SANs or running without SAN verification. If DNS is genuinely not viable, opening a feature request for a --experimental-peer-skip-server-san-verification flag is the cleanest way to get this into v3.6.x.