How to Rotate TLS Certificates Without Downtime
Almost every certificate outage is avoidable: the cert expired, or the new one went in without its chain, or the wrong process kept serving the old file. This guide walks through rotating a TLS certificate with an overlap window and a graceful reload so no request is ever dropped — and how to automate it so the next rotation needs no human at all.
In plain words
Rotating a TLS certificate without downtime means installing the new certificate while the old one is still valid, then swapping with a graceful reload — and PlayCISO has a free, browser-based Certificate Rotation Lab to practise it safely.
The whole technique is overlap: never let a certificate expire before its replacement is trusted, reload rather than restart so live connections drain, and automate renewal with ACME so expiry stops being a human responsibility.
Step by step
- 1
Inventory every certificate and its expiry
You cannot rotate what you cannot see. Enumerate every endpoint that terminates TLS — load balancers, reverse proxies, API gateways, internal service meshes, message brokers and client-auth stores — and for each record the subject/SANs, issuer, serial, key type and the notAfter date. A single forgotten internal certificate is the usual cause of a "sudden" outage, so track where the private key lives too, not just the public cert.
- 2
Stagger renewal dates instead of clustering them
If dozens of certificates expire in the same week you create a self-inflicted incident window. When you first issue or next renew, deliberately offset lifetimes so renewals spread across the calendar. Shorter lifetimes (the public CA maximum is trending toward ~47 days) force this discipline naturally and make each individual rotation low-stakes.
- 3
Issue the replacement during an overlap window
Request and install the new certificate while the old one is still valid, ideally 20–30 days before expiry. Reuse an existing CSR/key only if your policy allows key reuse; otherwise generate a fresh key. The goal is a period where both the outgoing and incoming certificates are trusted so you can cut over on your schedule, not the CA’s.
- 4
Load the new chain and reload — do not restart cold
Install the full chain (leaf + intermediates, in order) and private key, then issue a graceful reload (e.g. nginx -s reload, systemctl reload) so in-flight connections drain on the old worker while new connections pick up the new certificate. A hard restart drops live sessions; a reload swaps the cert with zero dropped requests on most servers.
- 5
Verify the served certificate from the outside
Confirm the endpoint is actually presenting the new leaf and a complete chain, not a cached old one. Check the served serial/fingerprint and expiry from a client’s perspective, and verify every SAN still matches the hostnames in use. A rotation that installed the cert but did not reload the right process looks "done" but still serves the old one.
- 6
Automate renewal with ACME
Move recurring rotations to an ACME client (certbot, acme.sh, lego, or a built-in like Caddy/Traefik) so issuance, installation and reload happen on a timer without a human. ACME renews early by default (typically at two-thirds of lifetime), uses HTTP-01 or DNS-01 challenges, and removes the manual step that causes most expiries. Keep DNS-01 credentials scoped tightly.
- 7
Monitor expiry independently and keep a rollback path
Alert on days-to-expiry from an external monitor (not the box doing the renewing) at, say, 21 and 7 days so a stalled automation is caught while there is still time to act. Keep the previous valid certificate and key archived so that if a new cert is mis-issued or missing an intermediate, you can reinstall the old one and reload within minutes.
Practise an overlap-window cutover, ACME renewal and a rollback on a live timeline — in your browser, with no real keys at risk.
Related
The map of certificate, key and TLS topics these labs build on.
Check if a certificate is revokedCRL vs OCSP and what to do when a check comes back unknown.
Certificate Chain LabMake sure the new cert ships a complete, correctly ordered chain before you cut over.
All PlayCISO labsHands-on, browser-based security labs across crypto, cloud and incident response.
Frequently asked questions
How early should I start rotating a certificate?
Begin the overlap window 20–30 days before expiry for manually managed certificates, and let ACME renew automatically at roughly two-thirds of the certificate’s lifetime. Starting early means a failed issuance or a missing intermediate is a non-event you fix calmly, not an outage you fight at 2am.
Does reusing the same private key make rotation safer?
It makes rotation simpler because the CSR and pinned public key stay the same, but it does not rotate the key material, so a key that may have been exposed stays exposed. Reuse keys only for convenience on healthy, never-exposed keys; generate a fresh key whenever you suspect compromise or your policy mandates periodic key rollover.
Why did my site break right after I "installed" the new certificate?
The two most common causes are forgetting to reload the process that actually terminates TLS, so it keeps serving the old cert, and installing the leaf without its intermediate so clients cannot build a chain. Verify the served certificate and chain from an external client after every rotation rather than trusting that the file on disk is what’s on the wire.
Can certificate rotation really be zero-downtime?
Yes, on virtually all modern servers. Installing the new chain and issuing a graceful reload lets existing connections finish on the old worker while new connections use the new certificate, so no request is dropped. Downtime only appears when people cold-restart the service or let the certificate expire before swapping it.
What should I monitor to avoid surprise expiries?
Monitor days-to-expiry from outside the renewing host so a broken automation is still caught, and alert at two thresholds (for example 21 and 7 days). Also monitor that the served certificate matches the one you expect, because a silent rollback or a stale cache can leave an expired or wrong certificate on the wire even when your automation reports success.