Why do consul TLS guides leave client in state where verify_incoming = false?

Consul
1

Seems that the docs to configure TLS Secure Consul Agent Communication with TLS Encryption | Consul - HashiCorp Learn as well as the doc to upgrade a cluster to TLS Update Consul Agents to Securely Communicate with TLS | Consul - HashiCorp Learn – both leave the clients in a state where verify_incoming is set to false.

Why is this? Do we actively want to leave the cluster in this state? Seems not secure.

For funsies, I set it to true, and restarted my client agents. All seems to be well. Am I missing something?

Thanks!

2

Hi @josh.m.sharpe,

When verify_incoming is set to true on a client agent, the HTTPS interface enforces client cert authentication. The first doc you shared only discusses securing Consul Agent Communication (rpc and gossip), not HTTPS.

This tutorial will provide you with a production ready TLS configuration for RPC and consensus communication. However, you will need to secure HTTP communication for the CLI and UI separately

While the second doc discusses client HTTPS encryption, it is missing the steps to explicitly enable the HTTPS port and disable the HTTP port.

ie:

ports {
  http = -1
  https = 8501
}

If you disable HTTP port and enable HTTPS port, you will have to follow additional steps to:

  1. Pass the CA cert to the CLI (using args or env variables) to verify the HTTPS endpoint. If you are using auto-encrypt, this CA Certificate will be that of ConnectCA (/v1/connect/ca/roots)
  2. Authenticate using a Client Certificate and Key

You can disable the client cert authentication but still retain one-way HTTPS by setting verify_inoming_https = false

In your testing, ensure you have enabled the HTTPS port to take full advantage of the verify_incoming=true settings.

This doc shows verify_incoming = true for client.

I hope this helps.

3

Ok, so, I’ve been busy securing gossip/RPC communication. My original post wasn’t asking about HTTPS for the web UI.

That said, I don’t believe this statement to be true:

When verify_incoming is set to true on a client agent, the HTTPS interface enforces client cert authentication. The first doc you shared only discusses securing Consul Agent Communication (rpc and gossip ), not HTTPS.

In my setup, I have verify_incoming=true on all my clients and servers. They’ve been restarted and I’m getting no errors in any logs. Consul seems to be working well. The web UI is still accessible without TLS on port 8500.

Maybe something to do with verify_incoming being deprecated. Not sure. I just updated my configs to use the new attributes tls { internal_rpc { ... } } – and all is still working as expected, and that explicitly doesn’t configure anything for HTTPS traffic.

Still leaves me wondering, why do/did the docs suggest that the internal RPC comms aren’t set up to verify incoming connections?

4

Hi @josh.m.sharpe,

Sorry if it was not clear enough. Port 8500 by default on Consul is the HTTP port, and even if you configure your TLS settings, 8500 will remain as HTTP Port (Plain Text).

You must explicitly enable the HTTPS interface on Consul by setting the value of ports.https > 0 if you want to secure your HTTP endpoints. See the last line of the linked page.

This is why in the sentence you quoted, I said, verify_incoming on client agents will enforce client cert auth for HTTPS interface (not HTTP). And HTTPS interface is not enabled by default on Consul.

I hope this is clear now.