Is there a way to extend RPC TLS CA certificate expiration without rotation?

Consul
1

Hi Consul community,

We’re managing a production Consul cluster and our RPC TLS CA certificates are approaching expiration (originally set to 10 years/3650 days). We’re trying to determine if there’s a way to extend the expiration date of our existing CA certificate without going through a full rotation process.

Our Current Rotation Process:

When rotating certificates, we use the following approach to maintain zero-downtime:

  1. Generate new CA and server certificates on a Consul instance using consul tls ca create and consul tls cert create

  2. Create a combined CA bundle containing both old and new CA certificates

  3. Update AWS Secrets Manager with the combined bundle

  4. Reload Consul + systemctl restart on all instances (using consul reload, NOT instance termination)

  • Followers first, then leader last

  • Each instance fetches the combined CA from Secrets Manager

Questions:

  1. Is there a way to extend the expiration date of an existing CA certificate without generating a new one? This would help us avoid the rotation process entirely for certificates that are otherwise still secure.

  2. Can you confirm our understanding is correct: The RPC TLS CA is completely separate from the Connect CA (auto-generated and stored in Raft), so rotating the RPC CA should NOT affect:

  • Service mesh operations

  • Connect CA roots

  • Service-to-service mTLS via Envoy

  • Connect intentions

  1. Does our rotation approach follow best practices? Specifically, using combined CA bundles with config reload and restart vs instance termination?

Any guidance would be greatly appreciated!

2

you cannot “extend” the validity of an already-issued X.509 certificate in-place. The Not After timestamp is part of the certificate’s signed data. Changing it would invalidate the signature.

Consul RPC TLS CA is separate from the Consul service mesh / Connect CA. The RPC TLS CA is configured in the agent TLS config files

On the other hand, the Connect CA is created when connect { enabled = true } is set in the consul config file, it’s used for securing service-to-service communication within the service mesh, it’s NOT for consul servers and agents communication. Also, the cert rotation for the this Connect CA will be done automatically.

3

You can actually have agents fully managed by the servers which can help reduce manual rotation requirements.

Auto_config will use the mesh CA for agents, it does require a JWT auth method to introduce the agents but once done the rest is now handled by the servers.