Plesk Let's Encrypt renewal failed

Plesk Let's Encrypt failures are usually webroot, quota, or extension issues—use panel logs plus SSH certbot traces.

When this happens

SSL It! shows renewal error for a subscription. Reseller accounts inherit broken DNS templates that omit glue records for customer zones used only for validation. Extension language packs sometimes surface generic renewal failure strings without the certbot detail hosting support needs.

Extension update broke compatibility with your nginx/apache combo mode. Reseller custom skins hide SSL warnings until expiry is seven days away. Custom nginx templates in subscriptions bypass panel webroot defaults without documentation.

First response

Plesk Let's Encrypt extension renewal failed—panel logs, webroot paths, quotas, and extension updates.

Searches for plesk lets encrypt renewal failed usually mean automated renewal failed, succeeded locally but never reached the TLS listener, or hit Let's Encrypt rate limits. The fix is almost always permissions, challenge reachability, or a missing reload—not buying a longer-lived commercial cert as the first move.

For Plesk Let's Encrypt renewal failed, read the ACME or panel error verbatim, run a dry-run renewal if your stack supports it, then confirm what certificate strangers receive on port 443 after you deploy. Certificate files on disk lie; only live handshakes matter for users.

Plesk wraps certbot with extensions and permissions per subscription. Failures show in panel logs with less detail than CLI unless you SSH. Check domain ownership, secured document root, and whether Repair Kit disabled extension cron. Triage should capture timestamps, account URLs, and the last Boulder error type before infrastructure changes widen blast radius. Pause destructive retries until you can cite the last Boulder error type and the challenge mechanism in use; random package reinstalls rarely fix presentation gaps.

See also ACME DNS-01 challenge propagation delays and ACME HTTP-01 challenge failed 403.

Why renewal failed

Plesk orchestrates certbot per domain with panel permissions. Panel-based issue hooks should log the subscription ID with Boulder errors so hosting support can find the affected customer without guessing. Shared hosting multi-tenancy means noisy neighbors can affect validation—correlate subscriptions.

Disabled SSL on alias domains still listed on certificate breaks validation. When nginx-only mode is enabled, ensure Apache is not still authoritative for webroot on older subscriptions migrated piecemeal. Extension and panel version matrices should be regression-tested quarterly.

Disk quota full prevents writing challenge files or new keys. Hosting support tiers should map extension error codes to customer-facing comms templates. Escalate with timestamps, hostnames, and serial comparisons attached so the next engineer does not repeat already-failed renew attempts.

Let's Encrypt extension requests certs per domain; custom vhost includes or disabled SSL on alias break validation. Clarify in tickets whether failure is validation, issuance, deploy, or listener presentment—teams too often mix these phases when reading logs. Multi-tenant panels amplify one misconfiguration across many customers—triage subscription identifiers early to avoid fleet-wide retries.

Not always Let's Encrypt outage—often local firewall on Plesk-managed nginx. Shared hosting density means one misconfigured subscription firewall rule can block HTTP-01 for multiple customer domains sharing an IP—correlate subscription IDs carefully.

Common causes

These patterns drive most plesk lets encrypt renewal failed tickets. They explain why automation logs look green while browsers or APIs still break.

Subscription disk quota full. Antivirus real-time scanning locking challenge files produces intermittent HTTP-01 failures that look like network flaps.

Wildcard attempt without DNS API in Plesk. Reseller-customized PHP open_basedir restrictions sometimes block webroot challenge file creation without obvious panel errors.

Mixed Apache/nginx modes confused webroot. Custom Plesk Docker hosting isolates webroot from panel-managed paths used by extension.

Diagnose

Re-run renewal from panel and tail plesk and letsencrypt logs. Correlate panel extension timestamps with letsencrypt logs on the host; customers often paste extension errors lacking the underlying certbot traceback.

tail -n 60 /var/log/plesk/panel.log
plesk ext-letsencrypt --help

Tail /var/log/plesk/panel.log and letsencrypt logs under domain; reproduce with plesk ext-letsencrypt CLI if available. Correlate subscription domain status (active/suspended) with ACME failure—suspended sites still on cert list fail validation. Request subscription PHP error logs when webroot challenges fail mysteriously—open_basedir errors rarely surface in the panel banner.

Fix step-by-step

Follow this sequence for plesk let's encrypt renewal failed. Capture command output after each step so the next responder can pick up without rerunning destructive changes.

1. Check subscription disk quota and clear space.
2. Confirm domain resolves and port 80 reachable for HTTP-01.
3. Update Plesk and Let's Encrypt extension.
4. Review vhost includes for secure docroot.
5. Retry renewal from SSL It!
6. External openssl customer domain.
7. Enable panel email before expiry.
8. Document which subscriptions use wildcards vs HTTP.
9. Archive redacted ACME logs and openssl transcripts in the ticket before closing.
10. Schedule a follow-up dry-run before the next natural renewal window.
11. Note Plesk build, extension version, and subscription ID in the closure summary.

Verify the live certificate

OpenSSL

echo | openssl s_client -connect HOST:443 -servername HOST 2>/dev/null | openssl x509 -noout -dates -subject -issuer

Replace HOST with the public hostname on the certificate. Run the same command after any reload or deploy change; acceptance means notAfter moved forward and serial changed versus the incident-opening capture.

How to read the output

Use Plesk SSL It! view plus external openssl on customer domain. Panel SSL views may cache presentation; openssl from outside confirms what browsers negotiate regardless of subscription UI optimism.

curl

curl -vI --connect-timeout 10 https://HOST/ 2>&1 | grep -Ei 'expire|SSL certificate|subject:|issuer:'

Replace HOST with the public hostname users request.

Roll out and verify

Re-run extension renew from panel after fixing reported issue.

Update Plesk and extension to supported combo. After extension upgrade, run panel repair on affected subscriptions before mass customer renewals.

Enable panel notifications before expiry. Publish a short post-incident note listing which hop served stale TLS and which command proved the fix so the next renewal inherits a checklist.

What to automate

Export extension failures to monitoring via log scrape. Scrape Plesk extension logs for patterns tied to subscription IDs. Correlate extension failures with subscription disk usage and nginx/apache mode flags before escalating to the CA. Panel screenshots alone rarely satisfy hosting partners reviewing repeated renewal failures on shared IPs or nginx-only subscriptions.

ssldays validates hosted domains when panel green does not match public TLS. ssldays validates customer domains when panel error text is vague. ssldays validates customer domains when panel SSL summaries lag behind live TLS negotiation.