I have a problem with self-signed certificates in an etcd cluster. The certificates are ok because if I use them in nginx, there is no error at all as long as I add the CA file to my certs store.

This is a capture of a curl --cacert ca.pem when using nginx. https://www.cloudshark.org/captures/7d145ab07ed2

However, if instead of using nginx I use etcd (which is the real service I want to setup), a curl --cacert ca.pem for example, throws curl: (35) Unknown SSL protocol error in connection to in Mac OS or curl: (35) gnutls_handshake() failed: Certificate is bad in Linux.

The following is a network capture when using etcd https://www.cloudshark.org/captures/124df64051af. As you can see in packet 21, server is returning a Bad certificate.

Some researching about curl error code 35 indicates that the reason might be:

  • Ciphers: not a problem, both using TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
  • Permissions: not a problem either, cert files are set to 644 and key files to 600.
  • Procotol: not a problem, both use TLSv1.2
  • Expired private key: it was just generated with 365 days of lifetime, so not expired.

If I use Chrome, I get ERR_BAD_SSL_CLIENT_AUTH_CERT. However, inspecting the console, it says the certificate is valid (because I added the CA to my store).

So really I'm out of ideas right now. What do you think might be the root of this issue?


It is visible from the packet capture that the etcd server requests a client certificate (CertificateRequest in Frame 12). You curl command lines do not include a client certificate which means that it will send an empty certificate (Frame 16). This results in the server (not the client) complaining about a bad (empty) (client) certificate.

You get a similar error in Chrome. It sees the certificate requests but has no client certificate to send so it complains about the missing certificate.

| improve this answer | |
  • mmm that makes sense. I have a side question though: is it common for the server to request a certificate from the client? Isn't it the other way around? – Ay0 Jan 25 '17 at 14:23
  • @Ay0 It's really not common, it's when the website need to strongly identify the user. – Tom Jan 25 '17 at 15:51
  • 1
    @Ay0: the server still sends its certificate so that the client can verify it to protect against MITM. But the server also wants to verify the client. Client certificates are usually used to authenticate the client in order to restrict access to a resource to specific clients only. It's not that common in the normal web because most use classical logins with password instead but it's actually useful because such a client certificate based authentication could also be handled by using a smart card or similar. – Steffen Ullrich Jan 25 '17 at 16:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.