Prevent SSL Expiry Outages — Recovery and Prevention

SSL expiry incidents are still one of the most avoidable causes of downtime. They look sudden from the outside, but in reality the warning signs start days or weeks earlier: renewal jobs fail quietly, DNS changes break validation, and nobody owns certificate lifecycle tracking.

If your team runs websites or APIs on shared hosting, a VPS, or a dedicated server, this guide gives you a practical prevention model, a fast recovery workflow, and a set of checks that reduce repeat incidents.

Recommended Hosting for This Use Case

For production sites where certificate hygiene matters, run on a stable Canadian Web Hosting Cloud VPS or Managed WordPress environment with monitored renewal and change controls.

Minimum: 2 vCPU, 4 GB RAM
Business-critical: 4 vCPU, 8+ GB RAM
Security baseline: DNS control, firewall discipline, renewal monitoring

What SSL Expiry Outages Usually Look Like

Before diving into fixes, it helps to recognise the symptoms. SSL failures present differently depending on the client and the service behind the certificate.

Browser errors: Chrome shows NET::ERR_CERT_DATE_INVALID, Firefox shows SEC_ERROR_EXPIRED_CERTIFICATE. Users see a full-page warning with no easy bypass.
API and webhook failures: Clients enforcing TLS verification (Python requests, curl with default settings, most payment gateways) reject the handshake outright. You will see SSL certificate problem: certificate has expired in logs.
Phantom downtime: Monitoring reports the endpoint as down even though the server process is running fine. The server is healthy — the certificate in front of it is not.
Checkout and login breakage: Any page behind HTTPS that processes form data stops working immediately. Revenue impact is instant for e-commerce sites.
HSTS trap: If your site previously sent an Strict-Transport-Security header, browsers will refuse to fall back to HTTP. An expired cert with HSTS means a complete site outage — there is no workaround for visitors until the cert is renewed.

How SSL Certificates Are Managed: Three Common Methods

The renewal method dictates how you troubleshoot. Here is what you are likely running:

SSL Method	Auto-Renew	Cost	Best For
cPanel AutoSSL (Sectigo)	Yes — cPanel managed	Free	Shared hosting
Let’s Encrypt (Certbot)	Yes — systemd timer	Free	VPS / dedicated
Commercial (DigiCert, Sectigo, etc.)	Manual renewal	$50–500/yr	EV/OV certs, compliance

cPanel AutoSSL: How Most Shared Hosting SSL Works

If you are on shared hosting with cPanel, your SSL certificates are almost certainly managed by AutoSSL. This is the single most important thing to understand if you are a CWH customer on a shared hosting plan.

AutoSSL is a cPanel feature that automatically provisions free DV (Domain Validated) certificates for every domain on your account. It runs on a schedule — typically once per day — and renews certificates before they expire. The default provider is Sectigo (formerly Comodo), though some servers use Let’s Encrypt as the AutoSSL provider.

Checking AutoSSL Status

Log into cPanel and navigate to SSL/TLS Status. This page shows every domain and subdomain on your account with its current certificate state: green means valid, yellow means expiring soon, red means expired or missing.

If you see a domain stuck in red, click Run AutoSSL at the top of the page to trigger an immediate check.

Common AutoSSL Failures

AutoSSL fails silently more often than people expect. The most common causes:

DNS not pointing to the server: AutoSSL validates by making an HTTP request to the domain. If your DNS A record points elsewhere (a CDN, a different server, or nowhere), validation fails. This is the number one cause.
CAA records blocking issuance: If you have set a CAA DNS record that restricts certificate authorities, and it does not include sectigo.com (or letsencrypt.org if your server uses Let’s Encrypt as the provider), AutoSSL will be denied.
Rate limits: Sectigo and Let’s Encrypt both enforce rate limits. If your account has many domains or you have been triggering repeated failures, you may hit a temporary block.
.htaccess redirects: A misconfigured .htaccess that redirects all HTTP traffic to HTTPS (before the cert exists) creates a loop that blocks the validation request.

Server-Side AutoSSL (WHM)

If you have WHM access or your hosting provider is troubleshooting, AutoSSL can be triggered per-user from the command line:

# Trigger AutoSSL for a specific cPanel user
whmapi1 start_autossl_check_for_one_user username=CPANEL_USER

# Check the AutoSSL log for errors
cat /var/log/apache2/autossl_log

Let’s Encrypt on VPS and Dedicated Servers

If you manage your own server, you are likely using Certbot with Let’s Encrypt. This gives you free 90-day certificates with automatic renewal — but only if the renewal pipeline stays healthy.

Checking Renewal Status

# List all managed certificates and their expiry dates
sudo certbot certificates

# Verify the renewal timer is active
systemctl list-timers | grep certbot

# Test renewal without actually renewing
sudo certbot renew --dry-run

Let’s Encrypt Rate Limits You Need to Know

50 certificates per registered domain per week: This counts all subdomains under the same root domain.
5 duplicate certificates per week: If you keep requesting the exact same cert (same set of names), you will hit this quickly.
Failed validation limit: 5 failures per hostname per hour.

If you have hit a rate limit, there is nothing to do but wait. Plan renewals carefully on domains with many subdomains.

Common Certbot Failures

Port 80 blocked: HTTP-01 validation requires an inbound connection on port 80. If your firewall (CSF, iptables, cloud security group) blocks it, validation fails every time.
Web server not reloaded: Certbot renews the cert files on disk, but if your post-renewal hook does not reload Nginx or Apache, the running process keeps serving the old (expired) cert.
Systemd timer disabled: After a server reboot or package upgrade, the certbot.timer can end up disabled. No timer means no automatic renewal.

Step 1: Confirm the Certificate State

Before changing anything, capture the current certificate details. This tells you exactly what expired, who issued it, and when.

# Check certificate validity, issuer, and subject
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -dates -issuer -subject

# Quick HTTP check
curl -Iv https://example.com

Record the exact expiry timestamp and issuer. You need this to verify that a renewal actually replaced the old cert, not just appended another one.

Step 2: Identify Why Renewal Failed

Most failures come from one of these:

ACME/Certbot timer stopped or failed
DNS record changed, breaking validation
Port 80/443 challenges blocked by firewall or proxy rules
Certificate files replaced in one service but not reloaded in another
AutoSSL disabled or provider misconfigured in WHM

# Certbot timer and service diagnostics
sudo systemctl status certbot.timer --no-pager
sudo journalctl -u certbot --since "7 days ago" --no-pager

# cPanel AutoSSL log
cat /var/log/apache2/autossl_log | tail -50

Step 3: Restore Service Fast (Emergency Renewal)

Use a controlled emergency path. Do not apply random certificate files copied from old servers.

Certbot (VPS/Dedicated)

# Dry-run first — if this fails, fix the underlying issue
sudo certbot renew --dry-run

# Actual renewal
sudo certbot renew

# Reload web server to pick up new certs
sudo nginx -t && sudo systemctl reload nginx
# or for Apache:
sudo apachectl configtest && sudo systemctl reload apache2

If dry-run fails, fix the challenge path or DNS first, then re-run renewal.

cPanel AutoSSL (Shared Hosting)

In cPanel, go to SSL/TLS Status and click Run AutoSSL. If you have shell access:

# Force AutoSSL check for one user
whmapi1 start_autossl_check_for_one_user username=CPANEL_USER

Step 4: Validate Full Chain and Service Reload

A successful renewal command is not enough. Verify that the running service is presenting the new certificate, not a cached copy of the old one.

# Re-check cert after reload — compare serial and dates
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -dates -serial

# Full chain validation via SSL Labs
# https://www.ssllabs.com/ssltest/analyze.html?d=example.com

Compare the serial number and expiry with what you expect. If the dates have not changed, the service did not reload properly — restart it fully rather than just reloading.

Step 5: Put Monitoring in Front of the Problem

Certificate expiry must be a monitored indicator, not a calendar reminder that someone might miss.

Command-Line Checks

# Check days until expiry for a single domain
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -enddate

# Bash one-liner: check multiple domains
for domain in example.com shop.example.com api.example.com; do
  expiry=$(echo | openssl s_client -connect "$domain":443 -servername "$domain" 2>/dev/null | openssl x509 -noout -enddate 2>/dev/null | cut -d= -f2)
  echo "$domain: $expiry"
done

Monitoring Tools

SSL Labs: Free, thorough analysis of your certificate chain, protocol support, and known vulnerabilities. Run it after every renewal.
Uptime Kuma: Free, self-hosted monitoring that can track SSL certificate expiry alongside uptime. Set it to alert at 14 days before expiry.
Prometheus + blackbox_exporter: If you already run Prometheus, the blackbox exporter can scrape TLS expiry and feed it into Grafana dashboards and alerting rules.

Set alert thresholds at 30, 14, 7, and 3 days before expiry. Route the 7-day and 3-day alerts to on-call, not just email.

Step 6: Add Change Management Guardrails

Many expiry incidents happen after an unrelated change. Someone migrates DNS to a new provider, updates the load balancer, or swaps the reverse proxy — and nobody checks whether the certificate validation path still works.

Post-change TLS check: After any DNS, proxy, or firewall change, run the openssl verification command above. Make it part of the deployment checklist.
Document certificate ownership: Every production certificate should have a named owner and a renewal method on record. When people leave or change roles, certificate ownership must transfer.
CDN and proxy awareness: If you use Cloudflare, a load balancer, or a reverse proxy, remember that you may have two certificates in the chain — the edge cert and the origin cert. Both can expire independently.

Step 7: Build a Certificate Inventory

Track every certificate by domain, environment, owner, renewal method, and expiry date. A spreadsheet works. A monitoring tool with SSL tracking is better. Teams without an inventory eventually miss a renewal during scaling or staff turnover.

At minimum, record:

Domain name and SANs (Subject Alternative Names)
Issuer (Sectigo, Let’s Encrypt, DigiCert)
Renewal method (AutoSSL, Certbot, manual)
Expiry date
Owner (who is responsible)

Step 8: Document the Recovery Runbook

Your incident runbook should include:

Validation commands (openssl, curl)
Renewal commands per stack (Certbot, AutoSSL, manual)
Service reload commands (Nginx, Apache, HAProxy)
Rollback decision points — when to revert a DNS change vs. force a renewal
Escalation contacts and response time expectations

Common Failure Scenarios

Wildcard cert not renewing

Wildcard certificates (*.example.com) require DNS-01 validation, not HTTP-01. This means Certbot needs API access to your DNS provider to create a TXT record. If the API token has expired or the DNS provider changed, renewal breaks silently. Validate provider credentials and check that the _acme-challenge TXT record is being created.

Cert renewed but browser still shows old expiry

The cert files on disk are new, but the running service is still serving the old one. This happens when the post-renewal hook fails to reload the web server, or when there are multiple terminating layers (CDN, load balancer, reverse proxy) and only one got the new cert. Validate every layer in the chain.

Only one subdomain broken

SNI (Server Name Indication) mapping issue. The web server is presenting a different certificate for that hostname, or the virtual host configuration points to the wrong cert files. Check the Nginx/Apache vhost configuration for that specific subdomain.

AutoSSL renews but the wrong cert is served

This happens when a commercial SSL certificate was previously installed for a domain. cPanel prioritises manually-installed certificates over AutoSSL. If the commercial cert expires and is not renewed, cPanel will not automatically fall back to AutoSSL. Remove the expired commercial cert from SSL/TLS > Manage SSL Sites to let AutoSSL take over.

Final Takeaway

SSL expiry outages are preventable with ownership, monitoring, and disciplined change controls. The tools are free — AutoSSL handles it automatically on cPanel shared hosting, Certbot handles it on VPS and dedicated servers, and a five-minute monitoring setup catches anything that slips through. If you combine certificate lifecycle checks with reliable infrastructure on Cloud VPS at Canadian Web Hosting, you eliminate this entire class of incident.

Prevent SSL Expiry Outages: A Practical Recovery and Prevention Guide