You click "Get it free" in Plesk's Let's Encrypt extension, wait for the spinner — and get an error. Or worse: the certificate issues successfully but nginx still serves the old expired cert and the browser shows a red padlock. In Plesk, Let's Encrypt failures fall into a short list of root causes: the ACME HTTP-01 challenge cannot reach the token file, nginx has a stale or missing certificate reference, the hosting type is misconfigured, or a recent Plesk upgrade left behind an orphaned cert entry.
This guide covers every common failure mode, with the exact CLI commands and Plesk UI paths to resolve each one.
💡 None of these worked? Skip the guesswork.
Get Expert Help →Step 1: Read the Real Error Before Clicking "Retry"
The Plesk UI often shows a one-line error that truncates the actual Let's Encrypt response. The full ACME error is always in the Plesk mail log.
grep -i "letsencrypt\|acme\|certificate" /var/log/plesk/panel.log | tail -30
Common error strings and what they mean:
Authorization token can not be found— The ACME HTTP-01 challenge file is unreachable (firewall, redirect, or webroot mismatch)SSLCertificateFile: file does not exist or is empty— nginx/Apache config references a cert path that no longer existsThe domain's DNS A/AAAA record does not point to the server— DNS propagation lag or wrong IP in the zonetoo many certificates already issued— Let's Encrypt rate limit (5 certs per domain per week)nginx is not installed or is disabled— Plesk requires nginx for forwarding-type hosting SSL
TOKEN="testtoken123"
mkdir -p /var/www/vhosts/yourdomain.com/httpdocs/.well-known/acme-challenge/
echo "test" > /var/www/vhosts/yourdomain.com/httpdocs/.well-known/acme-challenge/$TOKEN
curl -v "http://yourdomain.com/.well-known/acme-challenge/$TOKEN"
If curl returns a 301 redirect to HTTPS, the challenge will fail — Let's Encrypt follows redirects but many misconfigured Plesk setups redirect all HTTP to HTTPS before serving the token.
In Plesk, go to Websites & Domains → yourdomain.com → Hosting Settings and temporarily uncheck Permanent SEO-safe 301 redirect from HTTP to HTTPS. Issue the certificate, then re-enable the redirect.
Alternatively, add an ACME challenge exception to your nginx vhost configuration:
location /.well-known/acme-challenge/ {
root /var/www/vhosts/yourdomain.com/httpdocs;
try_files $uri =404;
allow all;
}
Place this block before the redirect rule and reload nginx: nginx -t && systemctl reload nginx
Let's Encrypt always uses port 80 for HTTP-01 validation, even if your site runs on 443 only. Check Plesk Firewall or the OS firewall:
# iptables / firewalld
firewall-cmd --list-ports | grep 80
# If missing:
firewall-cmd --permanent --add-port=80/tcp && firewall-cmd --reload
Plesk writes challenge tokens to the domain's document root. If the domain uses a custom document root (e.g., httpdocs/public), the Let's Encrypt extension may write to the wrong path. In Hosting Settings, verify the document root and ensure it matches where nginx serves files for the bare domain.
nginx -t 2>&1 | grep -i "does not exist\|no such file"
# or for Apache:
apachectl configtest 2>&1 | grep -i "SSLCertificateFile\|does not exist"
Note the full file path from the error output.
CERT_DIR="/etc/nginx/plesk.conf.d/vhosts"
MISSING_CERT="/path/from/error"
# Copy the default Plesk cert as a placeholder so nginx can start
cp /usr/local/psa/var/certificates/scf* "$MISSING_CERT" 2>/dev/null || cp /etc/plesk/default-ssl/default-ssl.pem "$MISSING_CERT"
nginx -t && systemctl restart nginx
Once nginx starts, you can reissue the correct Let's Encrypt certificate via Plesk.
/usr/local/psa/admin/sbin/httpdmng --reconfigure-all
systemctl restart nginx
systemctl restart httpd # or apache2
This regenerates all nginx and Apache vhost config files from Plesk's database, removing any stale certificate references.
openssl s_client -connect yourdomain.com:443 -servername yourdomain.com 2>/dev/null | openssl x509 -noout -dates -subject
Compare the subject CN and notAfter date against what Plesk shows in SSL/TLS Certificates.
Go to Tools & Settings → SSL/TLS Certificates (server level). If no default certificate is set, nginx uses the first cert it finds — which may not be yours. Select your Let's Encrypt cert and click Set Default. Restart nginx.
grep -r "ssl_certificate " /etc/nginx/plesk.conf.d/vhosts/ | grep yourdomain
The path should point to the renewed Let's Encrypt cert, typically at /etc/letsencrypt/live/yourdomain.com/fullchain.pem or Plesk's cert store at /usr/local/psa/var/certificates/.
Go to Websites & Domains → yourdomain.com → Hosting Settings. If the hosting type is set to "Forwarding", either:
- Switch to "Website" hosting type temporarily, issue the cert, then switch back
- Or enable nginx server-wide via Tools & Settings → Updates and reinstalling the nginx component
If you cannot expose port 80 (e.g., internal server or strict firewall), install the Let's Encrypt DNS validation extension in Plesk and use DNS-01 challenge. This validates ownership via a TXT record instead of an HTTP file — no port 80 required.
# Via Plesk CLI for DNS-01
/usr/local/psa/bin/extension --exec letsencrypt cli.php --domains yourdomain.com,www.yourdomain.com --email admin@yourdomain.com --challenge dns-01
nginx -t
apachectl configtest
openssl s_client -connect yourdomain.com:443 -servername yourdomain.com 2>/dev/null | openssl x509 -noout -dates -subject -issuer | grep -E "CN|notAfter|Issuer"
The Issuer should show Let's Encrypt and notAfter should be ~90 days in the future.
grep letsencrypt /etc/cron.d/* /var/spool/cron/root 2>/dev/null
Plesk's Let's Encrypt extension schedules auto-renewal via cron. If no cron entry exists, re-enable it in the extension settings under Domains → SSL/TLS → Let's Encrypt → Auto-renew.
Let's Encrypt failures in Plesk almost always trace back to one of five causes: ACME challenge blocked by a redirect, missing cert file crashing nginx, wrong default cert in the server block, incompatible hosting type, or a post-upgrade orphaned config. Work through the diagnostic steps above in order and you'll resolve the issue without needing to raise a support ticket. If you want Let's Encrypt auto-renewal managed proactively across multiple Plesk servers — with alerts before expiry rather than after — CloudHouse's managed server service handles certificate lifecycle as part of the standard SLA.
