Consul TLS cert rotation for Consul Client and Server on Kubernetes

Hi folks,

I’m trying to understand the strategy required for rotating Consul’s TLS certificates when they expire.

My understanding is that there are two CAs in use by Consul - one for the Consul Client and another for the Consul Server. In order for a given Pod to talk to Consul Client over HTTPS, it needs to trust the Consul Client CA. That’s fine - we’re using consul-k8s get-consul-client-ca in an initContainer to do that, and Pods talk to https://$HOST_IP:8501/ without any complaints.

But what happens in, say, 2 years’ time when the TLS certificate on the Consul Client expires? Presumably HTTPS requests to it will now fail since the cert is no longer valid.

I guess my question here is:
With auto-encryption enabled in the consul-helm chart, do the Consul Client and Consul Server pods automatically get new certificates?

Incidentally, I noticed a comment from @lkysow on the PR which enabled TLS for consul-helm, where he expressed concern over how certificates could be rotated:

^-- is there an answer/solution to this?

Thanks - Aaron

Hi Aaron, this is a great question. It’s going to take us some time to put together a detailed answer and we’ve scheduled doing this on our sprint. So we’re going to get back to you but not immediately.

1 Like

Thanks for the response, @lkysow. Glad to know it wasn’t just something I was misunderstanding.

On the same point, is it currently recommended to query the Consul Client via the $HOST_IP variable over HTTPS? We are currently connecting our applications to Consul Client at https://$HOST_IP:8501/v1/foo/bar

Are there any pitfalls or issues that could arise from this? Such as a cert suddenly changing/expiring, etc.?

For reference, we are retrieving the Consul Client CA using the consul-k8s get-consul-client-ca command and installing it into the container OS’s root store, and essentially relying on that for validating the certs Consul uses.