etcd: 3.2/3.3 etcd server with TLS would start with error "tls: bad certificate"

While debugging issues (might be relevant):

I have found that a single member etcd server on bootstrap will show error:

2018-03-07 22:36:51.136699 I | embed: rejected connection from "127.0.0.1:35160" (error "tls: failed to verify client's certificate: x509: certificate specifies an incompatible key usage", ServerName "")
WARNING: 2018/03/07 22:36:51 Failed to dial 0.0.0.0:2379: connection error: desc = "transport: authentication handshake failed: remote error: tls: bad certificate"; please retry.

Reproduce steps: https://gist.github.com/hongchaodeng/7d62f3b5d30b58c783c382d9b629b819

Note that 3.1.11 didn’t have this error log.

About this issue

Original URL
State: closed
Created 6 years ago
Reactions: 1
Comments: 23 (3 by maintainers)

Most upvoted comments

I meet the same issue etcd version 3.3.1 logs shown as follow Mar 09 13:37:33 master1 etcd[4197]: rejected connection from “192.168.9.186:31833” (error “remote error: tls: bad certificate”, ServerName “”)

+20

itnikita on Mar 9, 2018

This is still a problem with no clarity in the documentation for 3.4.

BongoEADGC6 on Dec 10, 2019

@nejtr0n , I don’t see “client auth” permission in your config for “server” key:

      "server": {
        "expiry": "8760h",
        "usages": [
          "signing",
          "key encipherment",
          "server auth"
        ]
      },

How to fix the issue: #9785 (comment) (add “client auth” to “server” profile in CA config and regenerate server cert).

KIVagant on Nov 9, 2018

How to fix the issue: https://github.com/etcd-io/etcd/issues/9785#issuecomment-432438748 (add “client auth” to “server” profile in CA config and regenerate server cert).

KIVagant on Oct 23, 2018

I guess this ticket is another example of https://blog.benwinding.com/github-stale-bots/

please reopen it, still happens in latest stable

XANi on Jun 4, 2021

I had the same issue in v3.4.9. I resolved it by adding clientAuth (TLS Web Client Authentication) to ETCD server certificate (used in ETCD_CERT_FILE). I’m not sure if, and why a server should have clientAuth flag in its certificate…

Avatat on May 31, 2020

I think this is probably a bug. Serving certs do not need clientAuth extend keyUsage because it is used as server certificate and should be authed by clients. I will check it later.

povsister on Jan 25, 2021

Resolved by adding client auth as an extended key usage in my cfssl config as recommended here (and evidently missing based on error output): https://coreos.com/os/docs/latest/generate-self-signed-certificates.html

tkellen on May 21, 2018