Plesk Let's Encrypt Certificate Not Working? Fix SSL Errors on Nginx & Apache

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 exists
• The domain's DNS A/AAAA record does not point to the server — DNS propagation lag or wrong IP in the zone
• too 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.