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:
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.
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.