SSL certificates expire. That is a feature, not a bug. The painful part is when renewal fails quietly and the first person who notices is a customer seeing "Your connection is not private" in Chrome.
Let's Encrypt and modern control panels made free HTTPS normal. They also made it easy to assume renewal is automatic forever. It usually is, until one DNS change, one firewall rule, or one forgotten subdomain stops the validation request.
How renewal actually works (quick version)
For HTTP validation (the common Let's Encrypt path), the certificate authority asks your server to prove it controls the domain. It hits a specific URL or DNS record. If that check fails, no new cert, and the old one ticks toward expiry.
Auto-renewal tools (Certbot, acme.sh, cPanel AutoSSL, Plesk) schedule retries before expiry. Managed hosting should monitor and alert. Unmanaged means you own the cron job and the inbox that ignores its failure emails.
Why renewals fail in real life
- DNS pointed elsewhere. Website moved to a new host but validation still expects the old server to answer.
- HTTP to HTTPS redirect loops or forcing www/non-www in a way that breaks the challenge path.
- Firewall blocks port 80. HTTP-01 validation needs port 80 reachable from the internet (or use DNS-01 instead).
- Forgotten subdomains. Cert covers www and apex but not shop.oldname or staging.client.com.
- Rate limits. Too many failed attempts in a week; Let's Encrypt throttles you.
- Expired server or broken cron. Certbot never runs because the renewal timer died six months ago.
- Wildcard certs without DNS API. DNS-01 needs API access to your DNS provider; manual TXT records expire if not updated.
Most of these show up in renewal logs days before the cert expires. Nobody reads the logs until the browser warning appears.
How to avoid surprise expiry
- Monitor expiry dates. Uptime tools, SSL monitors, or a monthly calendar reminder for non-auto environments.
- Test renewal, not just issuance. Run a dry-run renew (`certbot renew --dry-run`) after major DNS or server changes.
- Document every hostname on the cert. SAN list should match what you actually serve.
- Prefer DNS-01 for wildcards if your DNS provider supports automated TXT updates.
- Keep port 80 open for HTTP-01 unless you have deliberately moved to DNS validation everywhere.
- Reload the web server after renew. New cert on disk does not help if nginx/apache still serves the old file until reload.
cPanel, Plesk, and managed hosting
On shared and managed panels, AutoSSL or equivalent should handle single-domain and many subdomain cases. Failures often trace to:
- Domain not pointing at the server (parked elsewhere)
- Custom SSL manually installed and auto-renew disabled
- Proxy (Cloudflare orange cloud) misconfigured for validation mode
If you use Cloudflare or another CDN, understand whether SSL is "full" or "flexible" and whether the origin cert is managed separately from the edge cert.
What to do when renewal already failed
- Check expiry date in the browser padlock or `openssl s_client -connect yoursite.ca:443`
- Read the ACME / AutoSSL error log (exact message matters)
- Fix DNS or HTTP path so validation can complete
- Issue manually once if needed, then fix automation
- Confirm all vhosts reload and HSTS headers still make sense
Do not just click through the browser warning and hope clients do the same. Some will not come back.
Canadian hosting note
SSL is not a geography feature, but support timezone is. Swift Host manages renewals on managed plans and documents origin SSL when you front sites with a CDN. If you host with us and see a cert warning, open a ticket before guessing at DNS. Half the fixes are a single A record or an AutoSSL toggle.
Bottom line
Treat SSL renewal like backups: automate it, monitor it, and test it after anything changes in DNS or the web stack. Expired certs are almost always a process failure, not bad luck.
Seeing renewal errors or migrating hosts? Talk with Swift Host. We will trace validation failures and get HTTPS back before your customers notice.
