Let's Encrypt certificates are free and automatable, which is exactly why nobody thinks about them again after the initial setup — right up until one expires in production because a renewal job failed three months ago and nobody noticed.
Why renewal fails silently
Certificates issue for 90 days, and both certbot and aaPanel attempt renewal automatically once the certificate is within 30 days of expiry. The two most common failure modes: port 80 becomes unreachable (a firewall rule changed, or a reverse proxy config now redirects all HTTP traffic to HTTPS before the ACME challenge can complete), or DNS has changed and the domain no longer resolves to the server Let's Encrypt is trying to validate against. Both failures happen quietly — the renewal cron job runs, fails, and logs the error somewhere nobody is watching.
Setting it up with certbot
sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d yourdomain.com -d www.yourdomain.com
Certbot installs its own systemd timer (or cron job on older systems) that runs twice daily and only actually renews certificates within the 30-day window, so running it more often than that is harmless. Confirm the timer exists:
systemctl list-timers | grep certbot
Setting it up in aaPanel
Under the website's SSL tab, choose Let's Encrypt, select the domain(s), and issue the certificate. aaPanel schedules its own renewal check internally — no separate cron setup needed — but the same failure modes (port 80 blocked, DNS pointed elsewhere) will still silently break it, so the verification step below matters regardless of which tool issued the certificate.
Testing renewal before you need it
Don't wait for a real expiry to find out renewal is broken. With certbot, force a dry run:
sudo certbot renew --dry-runRun this right after initial setup, and again any time you change firewall rules, switch reverse proxy configuration, or move DNS to a new provider — all three are common causes of a renewal that worked fine for months suddenly breaking.
Monitoring expiry as a backstop
Even with auto-renewal configured correctly, add an external uptime monitor that specifically checks SSL certificate expiry (most budget-friendly monitoring tools support this as a check type — see our monitoring guide). It costs nothing and means you'll get an alert with two weeks of runway instead of an angry customer email the morning the certificate actually expires.
Common renewal errors and fixes
A few specific errors account for most real-world renewal failures:
- "Connection refused" or timeout during validation — port 80 is blocked by a firewall rule, or Nginx isn't listening on it. Confirm
curl -I http://yourdomain.comfrom an external machine actually reaches your server. - "Invalid response from ... 404" — Nginx is redirecting all HTTP traffic to HTTPS before the ACME challenge file can be served. Add an exception for the
/.well-known/acme-challenge/path that's served over plain HTTP, or let certbot's Nginx plugin manage this automatically rather than hand-rolling the redirect. - DNS mismatch — the domain no longer points at this server's IP, often after a migration where DNS was updated but the old certificate config wasn't. Renewal will keep failing until DNS and the server agree.
- Rate limiting — Let's Encrypt limits how many certificates you can issue for the same domain set within a week. This mostly bites people testing repeatedly; use the
--dry-runflag while testing, which doesn't count against the real limit.
Frequently asked questions
How often do Let's Encrypt certificates need to renew?
Every 90 days. Both certbot and aaPanel's built-in SSL manager attempt renewal automatically once a certificate is within 30 days of expiry, so a healthy setup renews itself roughly three times a year without any manual action.
Can I use Let's Encrypt for a wildcard subdomain certificate?
Yes, but wildcard certificates require DNS-01 validation instead of the simpler HTTP-01 method, which means your DNS provider needs to support the ACME DNS API (or you handle the TXT record update manually or via a plugin). This is the standard approach for multi-tenant apps issuing one certificate to cover all subdomains.
Is Let's Encrypt secure enough for a production SaaS handling payments?
Yes — Let's Encrypt issues standard domain-validated TLS certificates trusted by all major browsers, which is the same validation level used by the free or entry-level tiers of paid certificate authorities. Payment processing security depends on your overall implementation (PCI compliance, using a proper payment processor), not on which certificate authority issued your TLS certificate.