Plesk SSL certificate expired

Plesk ssl certificate expired breaks customer sites and the panel alike—browsers reject the leaf nginx or Apache binds, even when SSL/TLS still lists the domain as “secured.”

Hosting providers run Plesk 18.x on Ubuntu or AlmaLinux with nginx as a reverse proxy. Certificates renew per subscription, but service reloads or mixed Apache/nginx modes leave stale chains live.

Capture openssl from the internet before editing customer WordPress or PHP code.

First response

Identify whether the failure is a customer domain, a server hostname (panel.example.net:8443), or mail services (IMAP/SMTP submission). Note subscription ID and Plesk version from Tools & Settings → Server Information.

In Domains → example.com → SSL/TLS Certificates, screenshot expiry and assignment (“Certificate for securing mail” / “Certificate for securing the web site”). Check SSL/TLS Support is enabled for the domain.

SSH: note if plesk sbin nginx -t passes. Collect last lines from /var/log/plesk/panel.log and Let’s Encrypt logs if renewal ran recently. Compare panel “secured” badge to external openssl—support tickets often stem from that gap.

For reseller tickets, list all subscriptions on the affected IP—default SSL on shared IPv4 may serve an expired reseller cert to every customer vhost without proper SNI mapping. Note whether ModSecurity or fail2ban blocked Let’s Encrypt validation IPs during the renewal window.

What this error means

Plesk stores certificate files under /usr/local/psa/var/certificates/ and per-domain paths managed by the panel. Web servers reference those IDs in vhost metadata. When notAfter passes, clients fail PKIX validation immediately.

The panel UI may cache friendly status while nginx still serves an old certificate ID until Apply or a service reload completes. Mail uses separate bindings—web renewal does not always extend SMTP TLS.

For plesk ssl certificate expired, distinguish Let’s Encrypt automation failures (renewal path) from never-configured domains still on self-signed defaults after migration.

Common causes

Let’s Encrypt HTTP-01 fails when “Permanent SEO-safe 301 from HTTP to HTTPS” is enabled before challenges are reachable, or when custom nginx includes steal /.well-known. See Plesk Let's Encrypt renewal failed.

Commercial certificates expire without reseller automation; customers assume Plesk auto-renews everything. Wildcard attempts without DNS API credentials stall at pending.

Apache/nginx hybrid mode serves different docroots for challenges versus live site. Disk quota on a subscription blocks writing new keys. Repair Kit disables SSL-related cron.

Multi-domain certificates missing SAN for an alias domain show valid panel status for the primary only. IPv6-only vhosts with expired cert while IPv4 updated cause “works for me” reports.

Plesk ssl certificate expired on mail only still breaks mobile clients using autodiscover over HTTPS. WordPress Toolkit and other Plesk extensions surface admin UI over the same subscription hostname—renewal there does not fix customer domains if operators only patched panel :8443.

Confirm from the outside

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -dates -subject -issuer -serial

Panel access:

echo | openssl s_client -connect panel.example.net:8443 -servername panel.example.net 2>/dev/null \
  | openssl x509 -noout -dates -subject -issuer

curl -vIk --connect-timeout 15 https://example.com/ 2>&1 \
  | grep -Ei 'expire|SSL certificate|subject:|issuer:'

On server:

plesk bin certificate -l
plesk sbin nginx -t

How to read the output

Expired visitor-facing cert with valid panel cert means wrong certificate assignment on the subscription. Self-signed issuer on a production domain means default cert still bound—install a CA-signed chain. Plesk :8443 expiry blocks admins from fixing customer sites—prioritize panel hostname renewal.

Browser spot-check

Resellers sometimes access customer sites via preview URLs that bypass subscription cert—always test the literal customer domain name from a consumer browser profile.

Fix checklist

Work this list in order for Plesk SSL certificate expired. Hosting providers should note subscription id and PHP handler in the ticket closure for repeat-incident tracking.

1. SSL/TLS Certificates → Install or Let’s Encrypt → Install/ Renew for the affected domain.
2. Assign the new certificate to Securing webmail, mail, and web as needed.
3. plesk sbin nginx -t then plesk sbin nginx -s reload (or restart Apache per hosting stack).
4. If mail TLS errors, restart Postfix/Dovecot services Plesk manages.
5. External openssl each hostname; serial must update.
6. Remove duplicate expired certificate entries to avoid wrong UI pick.
7. For resellers, repeat on subscription template domains.
8. Document AutoSSL/Let’s Encrypt option for the client.

Roll out and verify

Hosting providers should sample five customer domains per reseller after fleet fixes, not only the ticket opener’s site. Restart ancillary services Plesk documents for the OS version—Onyx versus Obsidian paths differ for Dovecot restarts.

For plesk ssl certificate expired on :8443, verify resellers can log in before mass-mailing customers. Capture Plesk extension versions in the closure report; outdated LetsEncrypt extensions correlate with repeat incidents.

Schedule a follow-up dry-run renewal from SSL It! during business hours to confirm HTTP-01 still reaches the subscription docroot after any nginx template edits made during firefighting.

When to use automation

Panel notifications are per-server, not per customer portfolio. Use live TLS checks on representative domains per reseller and on the panel hostname 8443.

After remediation, /check customer domains from outside. ssldays scheduled monitoring catches subscription domains that stop renewing after DNS template changes.

Panel email about one domain does not cover the fleet—sample customer sites nightly on shared IPs. Track :8443 hostname cert separately from subscription AutoSSL. When resellers bulk-edit templates, run external TLS on three random customer domains before marking the incident resolved.

See Plesk Let's Encrypt renewal failed for ACME-specific errors and WHM hostname SSL expired when the control panel itself is unreachable.

Shared hosting NOC playbooks should list Plesk extension versions alongside OS minor releases because LetsEncrypt extension regressions cluster after unattended upgrades. Customers paste “SSL is enabled” screenshots while openssl shows expired material—train support to request external proof before escalating to tier three. When resellers white-label :8443, the hostname cert branding certificate may expire independently from customer AutoSSL jobs.

Mail-only TLS complaints on Plesk often trace to expired autodiscover or ActiveSync hostnames not visible in the main website SSL tab. Document which subscriptions use dedicated IPs versus shared IPs because default SSL presentation order affects SNI fallback during partial renewals.

For plesk ssl certificate expired, distinguish panel :8443, webmail, and customer vhost incidents in the subject line—mixed tickets slow resolution. Resellers should attach plesk bin certificate -l output redacted, not only customer screenshots. Closure criteria: external openssl on the reported domain plus two sibling domains on the same IP show future notAfter or documented exceptions for dedicated IPs.

Hosting providers should document which subscriptions use dedicated IP addresses versus shared pools because default certificate presentation affects how SNI fallback behaves during partial fleet renewals. Customer education articles can explain the difference between the Plesk panel padlock and the padlock visitors see in Chrome, reducing repeat tickets that blame application developers for hosting layer expiry.

Escalation paths between tier one support and infrastructure engineers need a mandatory external certificate check before permission to reboot entire nodes. Rebooting without renewing presentation wastes minutes while all tenants remain on expired material. Quarterly drills that renew a staging subscription end to end keep HTTP challenge paths familiar when production fails on a Sunday night.

Reseller billing teams should correlate SSL support tickets with plans that include premium backup or malware services, because customers on the highest tiers expect proactive expiry warnings. When multiple brands share one Plesk license, hostname and customer domain renewals should appear on one internal risk register. Overnight batch jobs that snapshot customer sites over HTTPS will fail in parallel with browser errors; pause them during renewal windows and resume only after external checks succeed on representative accounts. SLA reports to enterprise clients should cite independent TLS verification timestamps, not only Plesk panel screenshots that may misstate presentation. Managed WordPress clusters on Plesk still require per domain external checks because one subscription renewal does not prove every mapped domain received a reload. Joomla and Drupal subscriptions on the same server share nginx workers; a missed reload after one site renewal can still leave neighbors on stale chains until you restart the proxy. University labs teaching PHP should use staging subscriptions for ACME experiments instead of production merchant domains. Hosting CFOs should track revenue at risk during fleet certificate incidents using a count of subscriptions still presenting expired chains externally. Tier one agents should escalate when three unrelated subscriptions on one node report the same notAfter date. Document panel and customer impact in separate ticket fields.