KodeKloud Notes

In this guide, we’ll explore the three core TLS encryption options you can enable in your Consul agent’s configuration. By default, these settings are set to false, so you must explicitly activate them in your JSON or HCL config file. Enabling these options ensures all RPC/API calls in your Consul cluster are both encrypted and authenticated.

Quick Reference

Setting	Purpose	Default
verify_incoming	Enforce TLS on all incoming RPC and HTTP API calls	false
verify_outgoing	Enforce TLS on all outgoing connections	false
verify_server_hostname	Validate server hostname against certificate SAN	false

Here’s an example snippet showing all three enabled in JSON:

{
  "log_level": "INFO",
  "server": true,
  "key_file": "/etc/consul.d/cert.key",
  "cert_file": "/etc/consul.d/client.pem",
  "ca_file": "/etc/consul.d/chain.pem",
  "verify_incoming": true,
  "verify_outgoing": true,
  "verify_server_hostname": true,
  "ui": true,
  "encrypt": "xxxxxxxxxxxxxx"
}

1. verify_server_hostname

When verify_server_hostname is enabled, the agent checks that every outgoing TLS connection matches the server’s hostname against the certificate’s Subject Alternative Name (SAN). Without this check, Consul only validates the CA signature but not the actual hostname, leaving room for certificate spoofing.

The image provides information on TLS encryption settings, specifically focusing on hostname verification for outgoing connections and certificate requirements for Consul. It includes a diagram illustrating the certificate chain from root to intermediate to a specific node.

SAN Requirements

With Consul CA Server: Node certificates automatically include server.datacenter.consul by default.
With an External CA: You must add the SAN server.<datacenter>.consul (e.g., server.dc1.consul) when issuing certificates. Failing to do so will stop nodes from joining the cluster if verify_server_hostname is on.

SAN Requirement Warning

If you switch a client node to server: true without a proper SAN, the node will fail to join the cluster due to a hostname mismatch in its certificate.

Example: Web Server Agent

{
  "log_level": "INFO",
  "server": false,
  "key_file": "/etc/consul.d/cert.key",
  "cert_file": "/etc/consul.d/client.pem",
  "ca_file": "/etc/consul.d/chain.pem",
  "verify_incoming": true,
  "verify_outgoing": true,
  "verify_server_hostname": true,
  "encrypt": "xxxxxxxxxxxxxx"
}

2. verify_incoming

Enable verify_incoming to require TLS for all incoming connections, including both RPC and the HTTP API. The presenting certificate must be signed by a CA listed in your ca_file or ca_path.

The image explains TLS encryption settings, specifically the "verify_incoming" option, and includes a diagram showing client connections.

{
  "verify_incoming": true
}

3. verify_outgoing

When verify_outgoing is set to true, Consul enforces TLS on all outgoing connections from both clients and servers. The remote peer’s certificate must be signed by a trusted CA.

The image explains TLS encryption settings, specifically the "verify_outgoing" option, which requires outgoing connections to use TLS with a certificate signed by a CA. It includes a diagram showing connections between a server and clients.

{
  "verify_outgoing": true
}

By combining verify_incoming, verify_outgoing, and verify_server_hostname, you lock down your Consul cluster with end-to-end TLS encryption and strict certificate verification.

Links and References

Watch Video

Watch video content