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 "")
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.
Github question #9917: check ETCDCTL_API
variable, especially make sure --endpoints
is configured with https.
Runtime reconfiguration: try to reconfigure you etcd by updating/removing/adding etcs members.
nginx ingress: check your nginx ingress annotations
in case you are using nginx
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
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