clientv3: cert check fails when using multiple servers

[equinox0815]

We have a problem with HTTPs certificate checks using the clientv3 API.
Our test setup consist of 2 etcd instances (downloaded from https://github.com/coreos/etcd/releases):

etcd Version: 3.0.1
Git SHA: a4a52cb
Go Version: go1.6.2
Go OS/Arch: linux/amd64

They get started using the following script:

#/bin/sh

INST=$1

./etcd --name test$INST --trusted-ca-file certs/ca.pem --cert-file certs/etcd$INST.pem -key-file certs/etcd$INST-key.pem \
       --client-cert-auth --listen-client-urls https://192.0.2.$INST:2379 --advertise-client-urls https://192.0.2.$INST:2379 \
       --peer-trusted-ca-file certs/ca.pem --peer-cert-file certs/etcd$INST.pem --peer-key-file certs/etcd$INST-key.pem \
       --listen-peer-urls https://192.0.2.$INST:2380

192.0.2.1/32 and 192.0.2.2/32 are aliases on the loopback interface.

The certificates got generated using hack/tls-setup with a slightly changed Makefile. We just added -hostname 192.0.2.x to the call to cfssl for etcd1 and etcd2.
So we have 2 different certificates. etcd1.pem has X509v3 Subject Alternative Name set to IP Address:192.0.2.1 and etcd2.pem has X509v3 Subject Alternative Name set to IP Address:192.0.2.2.

Using openssl s_client -CAfile certs/ca.pem -connect 192.0.2.x:2379 we can confirm that both instances deliver the correct certificate. But when we do a query on the cluster the following happens:

ETCDCTL_API=3 ./etcdctl --endpoints https://192.0.2.2:2379,https://192.0.2.1:2379 --cacert=certs/ca.pem --cert=certs/client.pem --key=certs/client-key.pem get test                           
2016/07/05 14:03:10 grpc: addrConn.resetTransport failed to create client transport: connection error: desc = "transport: x509: certificate is valid for 192.0.2.1, not 192.0.2.2"; Reconnecting to {"192.0.2.1:2379" <nil>}
Error:  grpc: timed out when dialing

If we specify only one of the two endpoints everything works as expected.

It seems as if the client somehow mixes up the hostnames and endpoints.

[yorkart]

I have the same problem , the cert normal work on v2

[heyitsanthony]

@equinox0815 @yorkart it's a go-grpc bug. Submitted a patch to upstream: grpc/grpc-go#756