Renew SSL certificate via Let’s Encrypt with certbot (auto-renewal via systemd timer or cron), DNS-01 challenge for wildcards, or paid CA reissue flow. With the 47-day shift by 2029, manual renewal is no longer viable for any production site. The team that uses ACME automation has zero cert outages.
Table of contents
- The certbot auto-renewal
- Forcing a renewal
- DNS-01 for wildcards
- For paid CAs
- Cloud-managed certs
- Verifying renewal worked
- Reloading services after renewal
- FAQ
The certbot auto-renewal
Certbot installs a systemd timer (or cron) that runs twice daily:
sudo systemctl status certbot.timer
sudo certbot renew --dry-runThe timer runs certbot renew which checks if any certs are within 30 days of expiry and renews them. The team that has this timer running has automatic renewal every 60 days for 90-day certs.
Forcing a renewal
sudo certbot renew --force-renewalForce renewal even if cert isn’t near expiry. The team that tests renewal uses --force-renewal to verify the config works without waiting 60 days.
DNS-01 for wildcards
Wildcard certs (*.example.com) need DNS-01:
sudo certbot certonly --dns-cloudflare \
--dns-cloudflare-credentials ~/.secrets/cloudflare.ini \
-d example.com -d "*.example.com"Requires DNS provider API access. The team that uses DNS-01 has wildcard certs and supports internal services.
For paid CAs
Paid CAs (DigiCert, Sectigo, GlobalSign) have a reissue flow:
- Generate a new CSR (Certificate Signing Request).
- Submit to CA’s portal/API.
- Receive new cert + chain.
- Install on server.
The team that uses paid CAs has a CSR generation step + portal upload. Less automated than Let’s Encrypt.
Cloud-managed certs
AWS Certificate Manager, GCP Managed Certificates, Azure App Service Certificates:
- Auto-renewed by the cloud provider.
- Free (with the load balancer cost).
- No manual work.
The team that uses cloud-managed certs has zero cert work. The trade-off: vendor lock-in for the cert.
Verifying renewal worked
After renewal:
# Check expiry
sudo certbot certificates
# Verify from outside
curl -vI https://example.com 2>&1 | grep -i "expire\|subject"
# Or openssl
openssl s_client -connect example.com:443 -servername example.com < /dev/null 2>/dev/null | openssl x509 -noout -datesThe team that verifies has confirmation renewal worked.
Reloading services after renewal
Certbot can run a deploy hook:
certbot renew --deploy-hook "systemctl reload nginx"The team that uses deploy hooks has services that pick up the new cert without manual intervention.
FAQ
How often do I need to renew?
Let’s Encrypt: every 60 days (90-day certs, renew at 30 days remaining). Paid CAs: yearly (going to 47 days by 2029).
What if renewal fails?
Certbot notifies via email. The team that monitors email catches failures. The team that has monitoring on cert expiry (like https://github.com) catches failures within hours.
Can I auto-renew wildcard certs?
Yes - via DNS-01 with API access. Certbot’s DNS plugins support most major providers.
Should I use a paid CA or Let’s Encrypt?
Let’s Encrypt for most public sites. Paid CAs for EV certs, internal PKI, or compliance that requires OV/EV.
What about multi-domain certs (SAN)?
Let’s Encrypt supports up to 100 SANs per cert via -d flags. The team that uses SANs for multi-domain has one cert for many domains.
If you are sizing the infrastructure for the kind of project this post covers, the RunxBuild hosting calculator is the right place to model the line items. The compute, the memory, the storage, the bandwidth, the database - each one is a separate number, and the team’s mental model for the platform is the sum of those numbers. The RunxBuild dashboard is where the team sees the actual usage in one place.
Useful related references: