Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

clientv3: cert check fails when using multiple servers #5871

Closed
equinox0815 opened this issue Jul 5, 2016 · 2 comments
Closed

clientv3: cert check fails when using multiple servers #5871

equinox0815 opened this issue Jul 5, 2016 · 2 comments

Comments

@equinox0815
Copy link

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.

@heyitsanthony heyitsanthony self-assigned this Jul 5, 2016
@yorkart
Copy link

yorkart commented Jul 5, 2016

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

@heyitsanthony
Copy link
Contributor

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

heyitsanthony pushed a commit to heyitsanthony/etcd that referenced this issue Jul 14, 2016
heyitsanthony pushed a commit to heyitsanthony/etcd that referenced this issue Jul 14, 2016
heyitsanthony pushed a commit to heyitsanthony/etcd that referenced this issue Jul 14, 2016
heyitsanthony pushed a commit to heyitsanthony/etcd that referenced this issue Jul 15, 2016
gyuho pushed a commit that referenced this issue Jul 15, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

3 participants