SSL Certificate Renewal: How It Works and Why It Fails
How to renew an SSL certificate with Let's Encrypt, a host, or a paid CA, why renewals fail silently, and how shrinking certificate lifetimes change things.
An SSL certificate renewal is really a replacement. You do not extend the old certificate; you prove again that you control the domain, a certificate authority (CA) issues a brand-new certificate with a new expiry date, and your server has to start using it. Miss any of those three steps and the site keeps serving the old certificate until the day it expires — at which point every visitor sees a certificate has expired warning.
Renewal used to be a once-a-year chore. It is becoming a monthly one. The industry has agreed to shrink the maximum certificate lifetime in stages, so a process that worked “well enough” when a human renewed once a year will not survive what is coming.
How to check when your certificate expires
Before renewing anything, confirm the current state:
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
| openssl x509 -noout -issuer -datesnotAfter is the expiry date; issuer tells you which CA — and therefore which renewal process — you are dealing with. Or run the domain through the SSL certificate expiry checker, which shows days remaining, the issuer, and whether the chain is complete.
Renewal by certificate type
| Certificate | Who renews it | What you do | Typical failure |
|---|---|---|---|
| Let’s Encrypt via Certbot or acme.sh | Your server, automatically | Make sure the timer runs and the web server reloads | Timer disabled, challenge blocked, or server never reloaded |
| Managed by your host or CDN (cPanel AutoSSL, Cloudflare, Vercel, Netlify) | The platform | Keep DNS pointing at the platform | DNS moved elsewhere, so validation fails |
| Paid DV / OV / EV from a commercial CA | You | Buy renewal, validate, install new certificate and chain | Forgot to install, or installed without the intermediate |
| Load balancer / cloud certificate manager (AWS ACM, Azure, GCP) | The cloud provider | Keep the validation DNS record in place | Validation CNAME deleted during a cleanup |
Let’s Encrypt and Certbot
Let’s Encrypt certificates last 90 days, and Certbot is designed to renew them automatically when about 30 days remain. On most Linux installs a systemd timer or cron job runs certbot renew twice a day.
Check that it is actually scheduled and that a renewal would succeed:
systemctl list-timers | grep certbot
sudo certbot renew --dry-runThe most common silent failure is not the renewal itself — it is the web server never loading the new file. Certbot writes a fresh certificate to disk, nginx keeps serving the one it loaded at startup, and the site expires anyway. Add a deploy hook so the server reloads only when a certificate actually changed:
sudo certbot renew --deploy-hook "systemctl reload nginx"Other frequent causes: port 80 blocked by a firewall (breaking HTTP-01 validation), a CDN or redirect rule intercepting /.well-known/acme-challenge/, or DNS API credentials that expired (breaking DNS-01 validation for wildcard certificates).
Note that Let’s Encrypt stopped sending expiry reminder emails in 2025. If a renewal breaks, nothing from the CA will warn you anymore.
Host- and CDN-managed certificates
When the platform manages your certificate, renewal only fails if the platform can no longer prove you control the domain. That almost always means DNS changed: the domain was pointed at a new server, a CAA record now forbids the platform’s CA, or an A record bypasses the CDN. The renewal fails quietly inside the platform, and you find out when the old certificate expires.
Paid certificates from a commercial CA
These do not renew themselves. The steps are: purchase the renewal, generate a new private key and CSR (reusing an old key is possible but not recommended), complete domain validation again, then install the new certificate plus the intermediate bundle. Forgetting the intermediate is the classic mistake — the site works in desktop browsers that cache intermediates and fails in phones, API clients, and crawlers, often as an SSL handshake failure.
Certificate lifetimes are shrinking
In 2025 the CA/Browser Forum — the body of certificate authorities and browser makers that sets the rules — approved a phased reduction in the maximum validity of public TLS certificates:
| From | Maximum certificate lifetime |
|---|---|
| Before March 15, 2026 | 398 days |
| March 15, 2026 | 200 days |
| March 15, 2027 | 100 days |
| March 15, 2029 | 47 days |
The period for which a CA can reuse your earlier domain validation shrinks on a similar schedule. Let’s Encrypt has also announced it will shorten its own default lifetimes over the next few years, and it already offers six-day certificates for those who opt in.
The practical consequence: manual renewal stops being viable. At a 47-day maximum, a paid certificate renewed by hand needs attention roughly eight times a year, per domain. Anyone managing more than a handful of sites needs automated issuance through ACME, and needs to watch the result from outside, because more renewals means more chances for one to fail silently.
A renewal checklist
- Know who renews each certificate — you, the server, the host, or the cloud provider. Write it down per domain.
- Automate wherever ACME is available, and use a deploy hook that reloads the server.
- Test the automation with a dry run after any server, firewall, DNS, or CDN change.
- Serve the full chain, not just the leaf certificate.
- Check from outside after every renewal: the certificate the public receives, not the file on disk.
- Alert well before expiry — at least 14 days, so a failed renewal leaves time to fix it.
Why “it renews automatically” is not enough
Automatic renewal removes the chore, not the risk. The failure modes simply move: a timer disabled during a server rebuild, a firewall rule, a migrated DNS zone, a reload that never happened. Each one leaves an expiry date quietly approaching with nobody watching — the pattern behind almost every certificate that expired without warning.
SitesRadar’s free plan checks the certificate your site actually serves on a schedule — expiry, issuer, chain, and hostname — and emails you well before it lapses, alongside uptime, domain expiry, DNS changes, and broken links. For the full monitoring setup, see SSL certificate expiration monitoring.
FAQ
How do I renew an SSL certificate? It depends on the issuer. Let’s Encrypt certificates renew automatically through Certbot or another ACME client; host- and CDN-managed certificates renew themselves as long as DNS still points at the platform; paid certificates must be bought again, re-validated, and installed with their intermediate chain.
How long does an SSL certificate last? Let’s Encrypt certificates last 90 days. Commercial certificates could last up to 398 days until March 15, 2026, when the maximum dropped to 200 days. It falls to 100 days in 2027 and 47 days in 2029.
Why did my certificate expire if auto-renew is on? Usually the renewal failed validation (blocked port 80, changed DNS, expired DNS API key) or it succeeded but the web server was never reloaded, so it kept serving the old certificate.
Can I renew an SSL certificate early? Yes. Renewing early is normal and safe — Certbot renews at around 30 days remaining, and paid CAs let you renew weeks in advance, typically carrying unused time forward within the maximum allowed lifetime.
Do I need a new CSR to renew? For paid certificates, generating a fresh key and CSR is recommended. ACME clients such as Certbot handle this automatically.