You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For a etcd cluster using hostnames in TLS cert SANs, the etcd client only connects to the 1st etcd member in the endpoints list. Attempts to connect to the other members fail with:
W0924 14:42:29.368784 248333 clientconn.go:1120] grpc: addrConn.createTransport failed to connect to {https://member3.etcd.local:32379 0 }. Err :connection error: desc = "transport: authentication handshake failed: x509: certificate is valid for member3.etcd.local, not member1.etcd.local"
This causes an etcd client to become disconnected from the etcd cluster when the 1st etcd member is unavailable.
This appears to occur both with etcd 3.3.13 (which uses the old load balancer code) and 3.1.15 (which uses the new grpc load balancer)
The text was updated successfully, but these errors were encountered:
jpbetz
changed the title
etcd client failover fails certificate check on hostname mismatch
etcd client with multiple endpoints fails certificate checks due to hostname mismatch
Sep 24, 2019
(c.f. kubernetes/kubernetes#83028)
For a etcd cluster using hostnames in TLS cert SANs, the etcd client only connects to the 1st etcd member in the endpoints list. Attempts to connect to the other members fail with:
This causes an etcd client to become disconnected from the etcd cluster when the 1st etcd member is unavailable.
This appears to occur both with etcd 3.3.13 (which uses the old load balancer code) and 3.1.15 (which uses the new grpc load balancer)
Reproduction steps: https://github.com/jpbetz/etcd/blob/etcd-lb-dnsname-failover/reproduction.md
This can also be reproduced with etcdctl by stopping the 1st etcd and running:
which outputs:
xref: db61ee1
cc @gyuho @jingyih @liggitt @nerzhul @wenjiaswe
The text was updated successfully, but these errors were encountered: