dnephin
commented
2 years ago Thank you for raising this issue! It sounds like the problem is related to the new validation that was added in #10925 and #10964. i just noticed there is a problem with how we capture the error in that second PR, which is why the error message is nil instead of more helpful text.
The problem is most likely the TLS certificates you are using on the other servers. It could be the DNSName is not correct and doesn't match server.euw1.consul.
How did you create the certificates for the Consul servers? I'd suggest looking at the certs you have configured on each Server (they are configured using cert_file) to make sure they all have the expected DNSName, and that they all come from the CA configured using ca_file or ca_path.
Lord-Y
wesleyeleazar
gulavanir
Hi team,
I running a consul server cluster of 3 nodes VM. My consul version was 1.9.8, and I deciced to upgrade my cluster to 1.10.3 version and in here is what I saw in the logs:
Before making the upgrade I shut them all down and backup the data just in case as it's not a production server. After googling and not able to make things works, I revert my install with the old backup. I decided then to upgrade my 1.9.8 to 1.9.10 and unfortunately I got the same errors!
Reproduction Steps
Steps to reproduce this issue, eg:
My consul config is:
Consul info Server
Server info
``` agent: check_monitors = 0 check_ttls = 0 checks = 0 services = 0 build: prerelease = revision = 34a6478b version = 1.9.10 consul: acl = legacy bootstrap = false known_datacenters = 1 leader = false leader_addr = server = true raft: applied_index = 32774 commit_index = 0 fsm_pending = 0 last_contact = never last_log_index = 45589 last_log_term = 251 last_snapshot_index = 32774 last_snapshot_term = 116 latest_configuration = [{Suffrage:Voter ID:2afb25d5-8234-e9fc-dcef-babf75741651 Address:10.0.104.12:8300} {Suffrage:Voter ID:24a6c35e-9bab-7bae-9a31-ae94400ac1ef Address:10.0.104.13:8300} {Suffrage:Voter ID:3840bd0b-0980-8c1e-47c7-73bfef3bb5b9 Address:10.0.104.10:8300}] latest_configuration_index = 0 num_peers = 2 protocol_version = 3 protocol_version_max = 3 protocol_version_min = 0 snapshot_version_max = 1 snapshot_version_min = 0 state = Candidate term = 993 runtime: arch = amd64 cpu_count = 1 goroutines = 128 max_procs = 1 os = linux version = go1.15.15 serf_lan: coordinate_resets = 0 encrypted = true event_queue = 0 event_time = 34 failed = 0 health_score = 0 intent_queue = 0 left = 0 member_time = 3530 members = 10 query_queue = 0 query_time = 1 serf_wan: coordinate_resets = 0 encrypted = true event_queue = 0 event_time = 1 failed = 0 health_score = 0 intent_queue = 0 left = 0 member_time = 47 members = 3 query_queue = 0 query_time = 1 ```Logs fragments
Operating system and Environment details
Debian 10
Can someone tell me what's going on as the cluster was down after both upgrades? I don't have any other meaningful logs to provide but feel free to ask more if necessary. The firewal ports opened between the 3 servers are 8300-8302 (tcp), 8501-8502 (tcp), 8301-8302 (udp).