Skip to content
Rescue 404
Rescue

Plesk Problems

Plesk Let's Encrypt Failed

Intermediate Risk: medium

Last reviewed

Hosting access often needed Database access usually not needed

Direct answer

Plesk’s Let’s Encrypt issuance or renewal fails because the domain’s HTTP-01 validation request could not reach the server — usually DNS not pointing at the right IP, Cloudflare or another proxy intercepting port 80/443, the “Keep websites secured” option turned off, or a firewall blocking outbound validation traffic. Confirm DNS resolves directly to the server (or is DNS-only in Cloudflare during issuance), enable Keep Secured for the domain or plan, and retry the request from Domains → SSL/TLS Certificates before assuming the certificate authority itself is at fault.

Plesk automates free SSL/TLS through the SSL It! extension and Let’s Encrypt, but automation only works when the domain-validation challenge can actually complete. This guide covers how HTTP-01 validation, the Keep Secured auto-renewal setting, and common proxy/DNS interference fit together, then walks through the checks and fixes that resolve most failed issuance or renewal attempts.

Intermediate

Key facts

Verifiable numbers and definitions — each claim links to its source.

  • Let's Encrypt documents HTTP-01, DNS-01, and TLS-ALPN-01 challenge types to prove domain control before issuing a certificate. (Challenge Types)
  • Plesk's SSL It! extension docs cover issuing and managing SSL/TLS certificates (including Let's Encrypt) from the panel. (Securing Connections with SSL It!)
  • Let's Encrypt certificates are short-lived; their FAQ explains that clients must renew before expiry and that failed renewals leave the old certificate until it expires. (Let's Encrypt FAQ)

What the error means

Let’s Encrypt issues certificates only after confirming you control the domain, and Plesk’s SSL It! extension normally does this with the HTTP-01 challenge: Let’s Encrypt’s servers request a specific file over plain HTTP (port 80) at `http://yourdomain.com/.well-known/acme-challenge/…` and check the response against a token Plesk placed there. If that request cannot reach the real web server — because DNS points elsewhere, a proxy like Cloudflare intercepts the request without forwarding it, or a firewall blocks inbound port 80 — validation fails and no certificate is issued or renewed. Plesk also has a separate “Keep websites secured” setting (per domain or per service plan) that controls automatic reissue when a certificate is close to expiring; if that toggle is off, a previously working domain can simply stop renewing on schedule even though nothing else changed.

Common symptoms

  • Browser shows “Not Secure”, a certificate warning, or an expired-certificate error for a domain that used to be secure
  • Plesk SSL/TLS Certificates page shows a failed issuance/renewal attempt or an error referencing the ACME challenge
  • Manually clicking “Get it free” under Let’s Encrypt returns an error instead of issuing a certificate
  • Certificate is valid for the bare domain but not for `www` or a specific subdomain that should also be covered
  • Renewal fails specifically for domains proxied through Cloudflare (orange-cloud) while DNS-only domains renew fine
  • Certificate expired even though “Keep websites secured” appeared to be enabled
  • Let’s Encrypt notification email warns of an upcoming expiration with no successful renewal following it

Most likely causes

  1. 01 “Keep websites secured” disabled for the domain or the service plan’s SSL It! setting, so auto-renewal never triggers
  2. 02 DNS record for the domain (or the specific subdomain being validated) does not point at the Plesk server’s IP
  3. 03 Cloudflare or another proxy is set to proxied (orange-cloud) mode, intercepting the HTTP-01 challenge request instead of passing it through
  4. 04 Server firewall, security extension, or upstream network blocks inbound port 80 needed for HTTP-01 validation
  5. 05 IPv6 (AAAA) record present and misconfigured or unreachable, causing Let’s Encrypt’s dual-stack validation attempt to fail even though IPv4 works
  6. 06 Rate limiting from Let’s Encrypt after too many failed or duplicate requests for the same domain in a short window
  7. 07 Stale or leftover wildcard certificate request from SSL It! not cleaned up, blocking a fresh renewal for related subdomains

What changed before the problem started

  • Domain or subdomain was moved behind Cloudflare (or another CDN/proxy) after the certificate was first issued
  • DNS records were edited during a migration and no longer point directly at the Plesk server
  • A new AAAA (IPv6) record was added without matching working IPv6 connectivity on the server
  • “Keep websites secured” was turned off, either directly or because the domain was switched to a different service plan without that setting enabled
  • Server-level firewall or security rules were tightened, blocking port 80 traffic from Let’s Encrypt’s validation servers
  • Plesk or the SSL It!/Let’s Encrypt extension was updated and changed default behavior for existing certificates

Troubleshooting steps

  1. 01

    Confirm “Keep websites secured” is enabled for the domain

    Go to Domains → example.com → SSL/TLS Certificates and toggle “Keep websites secured” on if it is not already. For every domain on a shared plan, check Service Plans → plan name → Additional Services → SSL It! and set it to keep websites secured with free SSL/TLS certificates, then Update & Sync.

  2. 02

    Verify DNS points directly at the Plesk server

    Look up the domain’s A record (and AAAA if present) and compare it to the server’s actual IP address in Plesk’s server settings. A mismatch — old IP after a migration, or a CNAME pointing somewhere unrelated — will fail HTTP-01 validation regardless of anything else being correct.

  3. 03

    Temporarily set Cloudflare (or any proxy) to DNS-only during issuance

    If the domain uses Cloudflare with the orange-cloud proxy enabled, switch the relevant record to “DNS only” (grey cloud), trigger the Let’s Encrypt request in Plesk, wait for it to succeed, then re-enable the proxy. Repeated failures while proxied almost always trace back to this.

  4. 04

    Manually retry issuance or renewal from the SSL/TLS Certificates page

    Go to Domains → example.com → SSL/TLS Certificates → Reissue Certificate (or Get it free for a first-time request), select the subdomains to include, and submit. This surfaces the specific ACME error message rather than the generic renewal failure from a scheduled task.

  5. 05

    Confirm port 80 is open from the public internet to the server

    HTTP-01 validation requires an inbound connection on port 80 to succeed, even for an otherwise HTTPS-only site. Check the server firewall, any host-level security group, and ModSecurity/WAF rules to confirm they are not blocking or redirecting that path during validation.

  6. 06

    Check for and remove a stale AAAA (IPv6) record if IPv6 is not properly configured

    If the domain has an IPv6 record but the server’s IPv6 connectivity is not reliable, Let’s Encrypt’s validation from an IPv6 vantage point can fail even though IPv4 works fine. Removing an unnecessary AAAA record, or fixing IPv6 routing, resolves this class of intermittent failure.

When to stop troubleshooting

Stop retrying issuance blindly once you have confirmed DNS, proxy mode, and Keep Secured are correct and it still fails — at that point the cause is likely server-side (firewall, blocked scheduled task, or a Plesk extension issue) and needs host or admin-level access. Escalate with the full ACME error text, DNS records, and whether the domain is proxied through Cloudflare or another CDN.

Information to collect before requesting help

  • 01 Exact error text from the failed SSL/TLS Certificates attempt in Plesk
  • 02 Domain’s current A and AAAA records and the server’s actual IP address
  • 03 Whether the domain is proxied through Cloudflare or another CDN, and in what mode
  • 04 Whether “Keep websites secured” is enabled at the domain and/or service plan level
  • 05 Whether port 80 is reachable from the public internet to the server
  • 06 Whether the Let’s Encrypt/SSL It! scheduled task exists and last ran successfully
  • 07 Certificate expiration date and when the failures started

How a professional repairs the problem

A technician reads the full ACME error rather than the generic banner, confirms DNS resolves directly to the server and matches expected IPs, and checks whether a proxy like Cloudflare is intercepting the HTTP-01 challenge. They verify the Keep Secured setting and the underlying scheduled task, clear conflicting or stuck certificate requests, and open port 80 as needed at the firewall — then re-issue and confirm the certificate renews cleanly on schedule going forward.

Frequently asked questions

Why did my certificate stop renewing when nothing on my site changed? +
The site itself did not need to change — DNS, a proxy setting like Cloudflare’s orange cloud, or a firewall rule between Let’s Encrypt’s validation servers and yours can change independently and silently break the HTTP-01 challenge.
Does Cloudflare block Let’s Encrypt entirely? +
Not entirely, but proxied (orange-cloud) records can intercept the validation request before it reaches your server. Switching to DNS-only during issuance, or using DNS-01 validation if your setup supports it, avoids the conflict.
What does “Keep websites secured” actually control? +
It is Plesk’s SSL It! setting that automatically issues and renews a free Let’s Encrypt certificate whenever a domain would otherwise be left with an invalid, expired, or self-signed certificate. Turning it off stops that automation for the affected domain or plan.
Can I just install a paid certificate instead of troubleshooting Let’s Encrypt? +
Yes, that is a valid workaround for an urgent expiration, but the same DNS/proxy/firewall issue blocking Let’s Encrypt validation can also complicate future renewals of any certificate type — it is worth fixing the underlying reachability issue either way.
Why does the bare domain renew but not `www` or a subdomain? +
Each name in the certificate request needs its own successful validation. If `www` has a different or missing DNS record, or is proxied differently than the bare domain, it can fail validation independently while the main domain succeeds.
Is HTTP-01 the only validation method Let’s Encrypt supports? +
No — DNS-01 (a DNS TXT record) is also available and is required for wildcard certificates, but Plesk’s default SSL It! flow for standard domains typically relies on HTTP-01, which is why port 80 reachability matters so much for the common case.

Repair dispatch

Still Need Help Fixing Your Website?

If you are not comfortable editing website files, changing server settings, repairing a database, or troubleshooting a live website, professional help may prevent additional damage or downtime. We will review the problem before accepting the repair.

  • You will receive a clear explanation of the likely cause.
  • We will tell you if the issue falls outside our repair scope.
  • No additional work will be performed without approval.
  • A backup should be created whenever access and website condition allow it.
Emergency repair Request diagnosis

Do not share passwords through an unencrypted contact form — use Password Pusher (self-destructing link). Prefer a dedicated Rescue 404 admin account, not your personal owner login; if you cannot create one yet, we will add ours after repair.

Written by Josh

Last reviewed

Platform note: Full rescue available for WordPress and self-hosted sites. Wix, Squarespace, Webflow, Weebly, and similar closed builders have very limited backend access — fixes may not be possible. I will tell you honestly before we start.