How to fix etcd cluster "error "tls: first record does not look like a TLS handshake""

1/12/2019

I created a three node etcd cluester, config and start is already OK, but when I check the /var/log/messages, it shows

etcd: rejected connection from "172.17.0.3:43192" (error "tls: first record does not look like a TLS handshake", ServerName "")

How can I fix it ?

I have checked the health of etcd :

member 48b0dff99d5c867e is healthy: got healthy result from https://172.17.0.9:2379
member 646dab89331aabab is healthy: got healthy result from https://172.17.0.8:2379
member b45603216bfac234 is healthy: got healthy result from https://172.17.0.10:2379

That shows Ok, but when I cat the /var/log/messages, it always shows this error :

Jan 12 20:08:57 master etcd: rejected connection from "172.17.0.3:43160" (error "tls: first record does not look like a TLS handshake", ServerName "")
Jan 12 20:08:57 master etcd: rejected connection from "172.17.0.3:43162" (error "tls: oversized record received with length 21536", ServerName "")

-- Payton
etcd
kubernetes
ssl

2 Answers

1/14/2019

There is no solution from my side to fully help you with an issue but I've found couple of links that might help you in further investigations. Read them carefully, try solutions and I hope you will resolve the problem.

  1. Github question #9917: check ETCDCTL_API variable, especially make sure --endpoints is configured with https.

  2. Runtime reconfiguration: try to reconfigure you etcd by updating/removing/adding etcs members.

  3. nginx ingress: check your nginx ingress annotations in case you are using nginx

  4. google groups TLS handshake topic: Check this topic, especially comments related to VAULT_ADDR variable. I will copy paste last comment from thread here:

We were able to get everything to work, after understanding the permission issues.

You asked: "Please confirm if you are seeing server error messages before initializing Vault" Upon further examination, I did determine that the errors were not happening before initializing the Vault.

The problem ended up not being related to VAULT_ADDR, and we used the value: "http://127.0.0.1:8200"

I have the setup operation scripted, and it appears that not everything was being run at the proper permissions. At first I was running the scripts using the "sudo" command, which resulted in the failures. I discovered that the permissions for the certificate key were restricted and the file could not be accessed by my user. There may have been other permission issues as well. But once I switched user to root, and ran the script, everything behaved correctly.

Thanks

-- VKR
Source: StackOverflow

3/12/2019

for me helped

listen       443 ssl http2;
ssl on;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';
ssl_prefer_server_ciphers on;

in nginx config

-- Ryabchenko Alexander
Source: StackOverflow