An SSL certificate expires silently — no alarm, no warning to visitors beyond the browser's red padlock and "Your connection is not private" screen. At that moment, 80–85% of visitors abandon the site immediately. For an e-commerce store doing $2,000/day, even a 6-hour SSL outage costs over $500 in lost transactions — before accounting for the customers who won't return after seeing a security warning on your site.
SSL expiration is one of the most preventable causes of revenue loss in web hosting. This guide covers why certificates keep expiring despite automation, how to set up reliable renewal on Plesk, and how to manage SSL across multiple domains without a spreadsheet and a prayer.
The Real Business Cost of an Expired SSL Certificate
The numbers are stark:
- 80–85% of users immediately leave a site showing an SSL warning, according to GlobalSign research
- Google Chrome flags the site with a full-page "Not Secure" interstitial — most users never click past it
- Search rankings drop — Google confirmed HTTPS as a ranking signal; an expired cert triggers Chrome security warnings that increase bounce rate, which signals quality issues to Google
- Email delivery is disrupted — if your mail server's SSL cert expires, outbound SMTP connections to other mail servers fail TLS negotiation
- API integrations break — payment gateways, webhooks, and third-party integrations that verify SSL will start failing, often silently
For high-traffic sites, the revenue damage per hour of SSL outage can be calculated directly: average hourly revenue × 0.8 (abandonment rate) = minimum revenue loss per hour. A site doing $50,000/month loses roughly $1,100/hour during an SSL outage.
Why SSL Certificates Keep Expiring Despite Auto-Renewal
The frustrating reality: most Plesk servers have Let's Encrypt auto-renewal configured, yet certificates still expire. The common failure modes:
DNS validation failures
Let's Encrypt uses HTTP-01 or DNS-01 validation to verify domain ownership. If the domain's DNS has changed (new nameservers, Cloudflare proxy mode changed, DNS TTL issues) since the certificate was originally issued, validation fails silently and the renewal job marks itself as failed — while the existing certificate continues working until it expires.
Renewal task not actually running
Plesk's certificate renewal is handled by a scheduled task. If the Plesk task scheduler is broken, the server's cron is misconfigured, or the Plesk extension has an error, renewals simply don't run. The task appears configured but never executes.
Port 80 blocked for HTTP validation
Let's Encrypt's HTTP-01 challenge requires that port 80 be accessible from the internet. If a firewall rule, Cloudflare configuration ("Always Use HTTPS" without proper settings), or web server redirect blocks port 80, validation fails.
Wildcard and multi-domain certificates not covered
Plesk's Let's Encrypt extension manages per-domain certificates, but wildcard certificates (*.yourdomain.com) and certificates covering subdomains that aren't managed through Plesk require DNS-01 validation with manual or API-based DNS updates — a different process that's easy to miss.
Commercial certificate renewals forgotten
Paid certificates (Comodo, DigiCert, Sectigo) don't auto-renew — they require a manual renewal purchase, re-validation, and re-installation. With a 1-year validity, it's easy to miss the renewal window, especially when the original person who installed it has left the team.
💡 None of these worked? Skip the guesswork.
Get Expert Help →Setting Up Reliable SSL Renewal in Plesk
Enable Let's Encrypt with auto-renewal
1. Install the Let's Encrypt extension if not already installed: Plesk Admin → Extensions → Let's Encrypt.
2. Enable SSL for each domain: Subscription → Websites & Domains → domain → SSL/TLS Certificates → Let's Encrypt. Check "Secure the wildcard domain" if you use subdomains, and check "Assign the certificate to the mail domain" to cover mail.domain.com.
3. Verify the renewal task is scheduled: Tools & Settings → Scheduled Tasks → look for a task running plesk ext letsencrypt — it should run daily. If it's missing, add it manually:
plesk ext letsencrypt --renew-all
Monitor renewal status proactively
Don't wait for expiry alerts. Check renewal status regularly:
# Check all certificates and their expiry dates
plesk ext letsencrypt --info
# Check a specific certificate expiry via OpenSSL
echo | openssl s_client -connect yourdomain.com:443 2>/dev/null | openssl x509 -noout -dates
Set up expiry alerts outside Plesk
External monitoring catches failures in Plesk itself. Services like SSL Shopper (sslshopper.com/ssl-checker.html), UptimeRobot (free SSL expiry monitoring), or a simple cron job that emails you 30 days before expiry:
# Add to crontab — checks and emails if cert expires within 30 days
0 9 * * * /usr/bin/certbot certificates 2>/dev/null | grep -A2 "Expiry Date" | grep -v "VALID: [3-9][0-9]\|VALID: [1-9][0-9][0-9]" | mail -s "SSL expiry warning" [email protected]
Managing SSL Across Multiple Domains Without Missing Renewals
For servers hosting 20, 50, or 100+ domains, individual certificate management becomes a full-time job. The practical approach:
Audit your full certificate inventory
# List all SSL certificates managed by Plesk
plesk ext letsencrypt --info | grep -E "Domain|Expiry"
# Or check all domains for upcoming expiries
for domain in $(plesk db -e "SELECT name FROM domains" -N); do
echo | timeout 5 openssl s_client -connect ${domain}:443 2>/dev/null | openssl x509 -noout -enddate 2>/dev/null | echo "${domain}: $(cat)"
done
Separate Let's Encrypt from commercial certificates
Let's Encrypt 90-day certificates with auto-renewal are fine for most hosted sites. Use paid certificates with longer validity for domains where certificate changes require extra validation (EV certificates, domains with complex DNS setups). Track paid certificate renewals in a calendar with 60-day and 30-day reminders.
Use Cloudflare for unified SSL management
If domains are proxied through Cloudflare, Cloudflare manages the edge SSL certificate (Universal SSL, always valid, auto-renewed). You still need a valid certificate on your origin server, but Cloudflare's "Full" SSL mode only requires it to be present — not necessarily trusted — which simplifies the origin side.
The Hidden Problem: No One Owns SSL Monitoring
SSL certificates expire because no one owns the responsibility of monitoring them. In a small hosting company or agency, everyone assumes someone else is watching. The certificate renews automatically — until the one time it doesn't, and by then, a client's site has been showing a security warning for hours and you're fielding angry calls.
Managed server support includes SSL certificate monitoring as a standard component: automated checks across all hosted domains, alerts when a renewal fails or a certificate approaches expiry, and immediate action to resolve renewal failures before they cause outages. For any server hosting more than 10 domains, the cost of one prevented SSL outage covers months of managed monitoring.
CloudHouse Technologies monitors SSL certificates across all hosted domains as part of managed Plesk server support — so expired certificates stop being a 2 AM client emergency and become a non-event.
