Renewing an SSL certificate sounds like a solved problem: click renew, or let an ACME client handle it. In practice, renewal is where a surprising number of outages start, not because the renewal itself is hard, but because the certificate gets renewed in one place and never deployed to another, the chain comes out incomplete, or the automation quietly stopped working weeks ago. This guide covers renewing a certificate properly, whether you do it by hand or automatically, and how to confirm the new one is actually live.
Renew Automatically With ACME
For most public certificates, you should not be renewing by hand at all. An ACME client renews on a timer and reinstalls the certificate for you:
- Certbot, acme.sh, or lego for Let's Encrypt and other ACME certificate authorities.
- Caddy and Traefik renew automatically with no extra configuration.
- AWS ACM, Google-managed certificates, and most managed platforms renew transparently.
The catch with automation is that it fails silently. Certbot logs an error and moves on, and nobody reads the log. So the one thing worth adding is a check that renewal actually ran, which we get to below. With certificate lifetimes shrinking toward 47 days, automation is no longer optional for anything at scale.
Renew Manually From a Commercial CA
If you buy certificates from a commercial CA for longer validity, OV/EV, or specific compliance needs, the manual flow is:
- Generate a CSR and private key on the server. Keep the private key private, it never leaves the host.
- Submit the CSR to your CA and complete domain validation (DNS, HTTP, or email).
- Download the issued certificate and its intermediate chain. The intermediate matters as much as the leaf.
- Install both on the server and reload the service.
Deploy the New Certificate Everywhere It Lives
This is the step that causes outages. A certificate is rarely served from one place: you may have several web nodes behind a load balancer, a separate API gateway, a mail server, a CDN origin. Renewing on one box while the load balancer still serves the old certificate changes nothing for visitors.
Install the new certificate and the full chain, leaf plus intermediates, on every endpoint that terminates TLS, then reload each service so it picks up the new file. A missing intermediate is the classic renewal bug: the certificate validates in your desktop browser, which caches intermediates, while failing on a freshly installed server or mobile client. The TLS configuration guides at goodtls.com show exactly where each server expects the certificate and chain to live.
Verify the Renewal Actually Took
Never trust your own browser after a renewal, it caches aggressively. Verify from outside. Check the certificate on each hostname and confirm the new expiry date, then repeat for every name on the certificate: the apex, www, any API or mail subdomains, and each SAN on a multi-domain or wildcard cert. It is common to fix one hostname and leave another still serving the old certificate.
Stop Renewing by Memory
The renewal itself is a solved problem. Knowing that a renewal failed, before the certificate expires, is the part teams get wrong. Automation handles the routine case; monitoring catches the exceptions. SSL certificate monitoring tracks the expiry date on every certificate you serve and alerts you with lead time when one is not renewing on schedule, so a silent automation failure becomes an early warning instead of an outage. Pair this guide with our SSL certificate renewal checklist for the operational pre- and post-deployment steps, and if a certificate has already lapsed, what an expired certificate breaks and how to fix it gets you back up fast.