We have a setup with an ingress gateway in one datacenter and services that it routes to in other datacenters (using a failover block of a service-resolver) but it doesn't reflect in the topology view (running 1.9.7)
Is this something that is reflected in the topology in a newer version of consul? I wanted to ask before I submitted a feature request that has already been implemented
Hello, I've got Consul 1.9.7 installed with TLS. I used the built-in CA of Consul to generate the server and client certificates. I followed the Secure Consul Agent Communication with TLS Encryption tutorial. I now want to use the API and am getting some errors from
# curl -k https://localhost:8501/v1/agent/self curl: (58) NSS: client certificate not found (nickname not specified)
What might be the issue here?
"verify_incoming": true,in the configuration file. So from what I understand, I need to supply the relevant certificates with curl
# curl -vk https://localhost:8501/v1/agent/self --cacert /etc/consul/tls/<hidden>-agent-ca.pem --key /etc/consul/tls/<hidden>.pem --cert /etc/consul/tls/<hidden>-key.pem * About to connect() to localhost port 8501 (#0) * Trying ::1... * Connected to localhost (::1) port 8501 (#0) * Initializing NSS with certpath: sql:/etc/pki/nssdb * unable to load client cert: -8018 (SEC_ERROR_UNKNOWN_PKCS11_ERROR) * NSS error -8018 (SEC_ERROR_UNKNOWN_PKCS11_ERROR) * Unknown PKCS #11 error. * Closing connection 0 curl: (58) unable to load client cert: -8018 (SEC_ERROR_UNKNOWN_PKCS11_ERROR)
# curl -vk https://localhost:8501/v1/agent/self --cacert ./<hidden>-agent-ca.pem --key ./<hidden>-key.pem --cert ./<hidden>.pem * About to connect() to localhost port 8501 (#0) * Trying ::1... * Connected to localhost (::1) port 8501 (#0) * Initializing NSS with certpath: sql:/etc/pki/nssdb * unable to load client key: -8178 (SEC_ERROR_BAD_KEY) * NSS error -8178 (SEC_ERROR_BAD_KEY) * Peer's public key is invalid. * Closing connection 0 curl: (58) unable to load client key: -8178 (SEC_ERROR_BAD_KEY)
curlfrom source with
OpenSSLinstead of the CentOS default of
NSSand that solved my issue. The question remains, how can I overcome this with a default
curlin my CentOS distro that is compiled with
NSSand while using the built-in Consul TLS creation tool?
# ./curl/curl-7.67.0/src/curl -sk https://localhost:8501/v1/status/leader --key ./<hidden>-key.pem --cert ./<hidden>.pem | jq "<hidden>.<hidden>.<hidden>.<hidden>:8300"
server.dc1.consulneed to have the
serverprefix? For ex.
server.eu.mydomain.comor can it be
hostname.eu.mydomain.com? The tutorial isn't very informative on this matter (IMHO). What's the Consul internal usage for the word
serverin this case?
@epifeny I don't know what the Consul folks say about this, but when we generate server certificates, we include a laundry list of SANs (subject alternative names) to make sure that the cert includes all of the possible hostnames that we might use to reach the server, including the IP address and the Consul-based FQDN like consul-1.node.consul.
Yea, I don't think I'm gonna be able to get an answer for this. The docs are lacking detail.
consul tls cert create -server -dc dc1create a cert that has only server.dc1.consul, localhost, and 127.0.0.1? Why specifically server.dc1.consul that it itself does not even seem to resolve?
DNS:client.dc1.consul, DNS:localhost, IP Address:127.0.0.1
/v1/catalog/registeris expecting the full service definition (
api.AgentServiceRegistration), but I couldn't find any API to get it in the first place (in order to modify it).
/v1/catalog/service/also doesn't return all required values.
dnsmasqinstalled so that they will default query their own DNS instance. The rest of the servers in a separate VLAN use the standard DNS servers of the environment, which has a conditional DNS forwarder for
.consulthat forwards to the 5 Consul servers.
Hello! I have a flood of the following nasty warnings on my Consul installation (v.1.11.3):
[WARN] agent: Service name will not be discoverable via DNS due to invalid characters. Valid characters include all alpha-numerics and dashes.: service=sth-with_underlines
Unfortunately, in my case, service renaming is not feasible. At the same time, my setup does not use the DNS interface at all, so complete DNS disabling would be an appropriate solution, I think. I've tried to set a negative DNS port as suggested here: hashicorp/consul#3135 using CLI flag "-dns-port -1" , but it seems to have no effect.
Could you please advise if there is any way to disable DNS (or solve the warning problem)?