Etcd: warning: ignoring ServerName for user-provided CA for backwards compatibility is deprecated

[dabealu]

Hello everyone, what this warning means and how can I get rid of it ?
I created a 3 node etcd (v3.1.5) cluster, it works, but got this warning when, for example, I trying to get cluster health with etcdctl:

etcdctl --cert-file /etc/etcd/etcd.pem --key-file /etc/etcd/etcd-key.pem --ca-file /etc/etcd/ca.pem --endpoints='https://192.168.88.11:2379,https://192.168.88.12:2379,https://192.168.88.13:2379' cluster-health

2017-04-02 11:50:38.683593 I | warning: ignoring ServerName for user-provided CA for backwards compatibility is deprecated
2017-04-02 11:50:38.684441 I | warning: ignoring ServerName for user-provided CA for backwards compatibility is deprecated
member ae103ab83d58f03 is healthy: got healthy result from https://192.168.88.12:2379
member 10fc6e18147d72d1 is healthy: got healthy result from https://192.168.88.13:2379
member 2a35a747c2e30e40 is healthy: got healthy result from https://192.168.88.11:2379
cluster is healthy

All certs are created with cfssl:

# generate ca-key.pem and ca.pem:
echo '{\"CN\":\"kubernetes\",\"hosts\":[\"192.168.88.11\",\"192.168.88.12\",\"192.168.88.13\"],\"key\":{\"algo\":\"rsa\",\"size\":2048},\"ca\":{\"expiry\":\"99999h\",\"usages\":[\"any\"]}}' \
  | cfssl gencert -initca - \
  | cfssljson -bare ca -

# then I get cert and keyfile for each etcd node from cfssl API endpoint like this:
curl -skd '{"request":{"hosts":["node-1","192.168.88.11","127.0.0.1","localhost"],"CN":"node-1"}}' \
      https://CFSSL_API_IP:8888/api/v1/cfssl/newcert >keypair.json

What openssl says about ca.pem:

openssl x509 -text -in ca.pem

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            3b:db:4f:dd:8c:de:e1:98:7f:5c:90:00:56:6b:d0:99:76:a7:c1:04
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN=kubernetes
        Validity
            Not Before: Apr  2 11:31:00 2017 GMT
            Not After : Aug 29 02:31:00 2028 GMT
        Subject: CN=kubernetes
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:

                      ...cut some output here...

                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Certificate Sign, CRL Sign
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Subject Key Identifier: 
                51:4D:2E:DB:ED:D1:6B:30:DB:C8:1E:13:34:47:23:5D:D9:BE:C3:2B
            X509v3 Authority Key Identifier: 
                keyid:51:4D:2E:DB:ED:D1:6B:30:DB:C8:1E:13:34:47:23:5D:D9:BE:C3:2B

            X509v3 Subject Alternative Name: 
                IP Address:192.168.88.11, IP Address:192.168.88.12, IP Address:192.168.88.13
    Signature Algorithm: sha256WithRSAEncryption

         ...cut some output here...

[heyitsanthony]

It's benign, it's meant to communicate the TLS policy is going to be strengthened. Having this warning all the time is ugly, though. The client could possibly inspect the net.Conn address to see if it matches any ServerName in the TLS configuration and warn if there's a mismatch.

[dabealu]

Thanks for your reply !
So if I understand correctly there's no way currently to get rid of this warning.
But what to expect in the future versions of etcd according to this upcoming change and what requirements CA must met ?
It will be very helpful to get some docs about it and maybe some examples how to handle this via cfssl or openssl.

[heyitsanthony]

If a ServerName is in the server's cert, then it must match the server that's replying. It only matters if your TLS setup is broken; the old policy of ignoring it was too permissive.

[timn]

Well, in the code it explicitly resets ServerName if passing a ca file option. Using the same CA, but putting it in the system's TLS trust anchors and then just not passing the CA argument makes this warning go away, but we have not made it a iota safer or unsafer. I don't really see why etcdctl does what it does.

[heyitsanthony]

@timn it does not reset it in 3.2. There's a warning because it had the insecure behavior in the past and people have complained about locking down TLS without a warning message first.

[timn]

@heyitsanthony I see, thanks for the clarification.

The warning message is just causing more confusion then helping. It references some code internals, rather than pointing to some source of information what that means, what needs to be done.

So, as it does accept my CA now if installed system-wide, I assume 3.2 should just accept it without warning again as a command line argument?

[heyitsanthony]

@timn the warning will be gone in 3.2 and not reset ServerName (it's already done in master). If it were up to me I would've locked it down in 3.1 without a warning at all since it's carrying a dangerous misconfiguration (the best warning would be broken certs being directly rejected).

/cc @philips

[heyitsanthony]

Closing this since there's a workaround and the warning will be gone in 3.2.0

[ae6rt]

Sorry for commenting on a closed issue, but this is important and there is an implication in this comment https://github.com/coreos/etcd/issues/7647#issuecomment-292580176 that needs to be challenged, namely that the TLS configuration of the OP was broken. Maybe I read the comment wrong, but @dabealu addressed his cluster members by IP address, and those IP addresses appear as Subject Alternative Names in his server certs. If he provided the CA cert on the command line to etcdctl, then the X509 path should validate and hostname verification should have worked, as the addressed URL uses an address that appears as a certificate SAN. How is that broken? What exactly is complaining about ServerName, and what exactly is ServerName (is it the etcd instance's --name parameter)?

@heyitsanthony says the warning does not appear in 3.2. Does this mean whatever was complaining about ServerName is not going to deprecate and fail what it was complaining about?

[heyitsanthony]

@ae6rt it's just saying that it's being more permissive than it should be for ServerName mismatches; it's not detecting if there is a mismatch. It is less permissive and locked down in master / 3.2.