CODEWITHSUNDEEP
sslkubernetesetcd
Payton
Payton

Reputation: 41

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

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 "")

Upvotes: 4

Views: 13310

Answers (3)

Anonym
Anonym

Reputation: 1

Small Remind. If you got problems same as this. TLS Handshake. First of all check, What service IS REJECTING. As we can see here "master etcd: rejected connection from "172.17.0.3:43160", master - a DNS name that's not in the cert file. This is the main problem. FIX: add in self-assigned ceritificate DNS names of etcd master/slaves.

Upvotes: 0

Nicolai Langfeldt
Nicolai Langfeldt

Reputation: 109

I got this message for the etcd peer communication when switching from http to https for peer communication. Apparently etcd has persistent peer information that overrides the command line options so it continued to use http for peer communication in spite of the command line options.

In the end, since this was a test cluster, I nuked /var/lib/etcd and the new cli configuration took hold

Upvotes: 4

Vit
Vit

Reputation: 8411

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

Upvotes: 0

Related Questions