Fix Plesk Let's Encrypt certificate renewal failures

The daily Could not issue/renew Let's Encrypt certificates for <customer> email Plesk sends its admin is a summary, not a diagnosis. The actual reason is in the renewal log, and the five common causes need five different fixes. This is the Plesk equivalent of the WHM AutoSSL decision tree — find the first real error line, then match it below.

Read the real error first

Don't act on the email. Pull the renewal log and the exact ACME error:

tail -200 /usr/local/psa/var/log/letsencrypt-renewal-$(date +%Y-%m-%d).log

To reproduce a single failing domain interactively and see the live error, run the extension CLI directly:

plesk bin extension --exec letsencrypt cli.php -d example.com -d www.example.com

Now match the first error: or Authorization ... failed line.

1. "Timeout during connect" / "Connection refused" / 404

HTTP-01 validation. Let's Encrypt can't fetch the token from http://example.com/.well-known/acme-challenge/. Three sub-cases:

• Port 80 filtered — a firewall (Plesk Firewall, the provider's edge, or an upstream appliance) is blocking inbound 80. Validation always starts on HTTP even when the site is HTTPS-only. Confirm from outside: curl -I http://example.com/.well-known/acme-challenge/test.
• 403/404 from a WAF or .htaccess — a force-HTTPS or WordPress security rule eats the challenge path. Add an early exit above any redirect block in the domain's .htaccess: RewriteRule ^\.well-known/acme-challenge/ - [L].
• Domain points elsewhere — the A record resolves to a parking service or the old host. dig +short example.com A must return this server's IP. No fix on the server side until DNS is corrected.

2. "Incorrect TXT record" at _acme-challenge

DNS-01 validation, and Plesk is not authoritative for the zone. This is the classic external-DNS case — Route 53, Cloudflare, or a registrar's nameservers — where Plesk writes the _acme-challenge TXT record into its local zone but the world queries somewhere else.

Two fixes: either point the domain's NS records at Plesk so its DNS is master, or install the matching DNS provider extension (Cloudflare, Route 53, etc.) so Plesk pushes the TXT record to the real provider over API. Check the local DNS service is even running under Tools & Settings → Services Management — if it's stopped, no TXT record is generated at all.

3. "NXDOMAIN looking up TXT for _acme-challenge" (wildcards)

Wildcard certificates (*.example.com) require DNS-01 — HTTP-01 is not allowed by Let's Encrypt for wildcards. If you see NXDOMAIN, either no DNS plugin is configured, or you issued before propagation. With a provider plugin in place:

plesk bin extension --exec letsencrypt cli.php -d example.com -d "*.example.com"

Wait for the TXT record to resolve globally before retrying: dig TXT _acme-challenge.example.com +short.

4. Rate limited

Let's Encrypt limits are per-domain and unforgiving. Match the wording:

5. Stale chain or conflicting certificate

Existing certificate has a CN that conflicts or a chain mismatch means a third-party or old cert is still bound. Remove it under Websites & Domains → SSL/TLS Certificates, then re-secure with Let's Encrypt. If the panel state looks inconsistent, rebuild the web config with the Plesk repair utility: plesk repair web example.com.

If renewals fail across every domain at once — not one — the problem is usually the panel itself, not the certificates. Check for a broken update or missing components, covered in fixing Plesk update failures, and confirm your Plesk license is valid, since an expired license can disable the secure-site automation.

Next steps

• Plesk repair utility commands — rebuild web and DNS config from CLI
• Fix Plesk update failures — when renewals break fleet-wide
• Fix Plesk license errors — rule out license-disabled automation