We have consul deployed in EKS using Helm Chart. TLS is configured on the server and the clients. A custom server certificate and CA certificate is provided as input to the helm chart.
The installation and usage is working all ok.
We notice that the clients have their own ssl certificate that is signed by the same CA that was used for the server certificate with a 1yr validity period.
As these certificates are generated when the (client) container is created (on instantiation ), the certificate validity is not known upfront.
To ensure the ssl certificate doesn’t expire on a client, the client container needs to be restarted before the ssl certificate expires.
Is there a automated feature to restart the client containers or do we need to set up a monitor and run a job to restart the containers?
We recommend turning on auto-encrypt feature which will enable servers to automatically rotate client certificates: Helm Chart Configuration | Consul by HashiCorp
This features enables clients to ask servers to provision their certificates. Servers will then manage it just like we manage it for service mesh certificates: auto-rotating leaf certs before they expire and helping with CA rotation (Connect - Certificate Management | Consul by HashiCorp).
Hope this helps.
auto-encrypt does solve the problem around certificate rotation but it brings up another problem. The CA used during auto-encrypt is not the CA thats specified in the tls:caCert:secretKey.
When services send out a request to the consul client, we store the consul CA cert in /etc/ssl/certs ssl to check the cert validity but that won’t be possible now.
This CA problem will also apply for services that need to access consul client from outside the cluster.
Is there an option to create a cert using consul cli i.e. consul tls create -client and load that into secrets? This option listed in this article seems promising but its not working yet.