TLS verification and web UI


I am wondering: When you enable “verify_incoming” and “verify_outgoing”, you just can’t reach the Consul UI anymore, as the Consul servers expect a TLS cert to be sent along with the client request.

I’m curious how ppl have solved this. Do you run a local agent with it’s own TLS keypair and exposes the UI, and connect your browser to the local agent? Do you put a reverse proxy in front it which uses a TLS keypair to connect to the backend servers? Or another solution?

Hi Jeroen,

The solution for this is to set the verify_* flags differently on servers that are going to run the UI.

Our guide on securing RPC communications has a section with details on how to access the UI when TLS is enabled:



1 Like

This is exactly what I was looking for. Thanks! :slight_smile:

I’m not sure I understand how the auto_encrypt feature works.

Nowhere in the server config file, I see reference the CA private key that was created with consul tls ca create command. How does auto_encrypt knows which private key to use to sign the client certs?

I also seems I had an incorrect understanding of how Consul TLS works. I always assumed that Consul certs had to include the full FQDN of the host, but the consul tls commands don’t do this by default. client certs generated by consul tls only seems to contain client.<dc>.<consul_domain> as CN and server certs only contain server.<dc>.<consul_domain>.

Is it correct that Consul ignores the values of the CN and SAN values by default, unless verify_server_hostname is being used, and even then, it only needs to contain server.<dc>.<consul_domain> ?

»Note on SANs for Server and Client Certificates

Using localhost and as Subject Alternative Names in server and client certificates allows tools like curl to be able to communicate with Consul’s HTTPS API when run on the same host. Other SANs may be added during server/client certificates creation with -additional-dnsname to allow remote HTTPS requests from other hosts.

Seems I missed this part :slight_smile: