Plesk Let's Encrypt Auto-Renewal Not Working: Complete Fix Guide (2025)

Your Plesk server quietly tries to renew Let's Encrypt certificates every 60 days. When it works, you never think about SSL. When it fails, your site throws a browser security warning, visitors bounce, and search rankings drop — often hours before you even notice.

This guide covers every confirmed root cause of Plesk Let's Encrypt auto-renewal not working in 2025, with exact error messages, CLI commands, and step-by-step fixes.

Why Plesk Let's Encrypt Auto-Renewal Fails (Root Causes Overview)

The SSL It! extension in Plesk handles Let's Encrypt issuance and renewal. When auto-renewal stops working, the failure almost always traces back to one of these five root causes:

• "Keep Secured" is not enabled — the domain or service plan is not configured to auto-renew.
• ACME HTTP-01 challenge failure — the Let's Encrypt validation server cannot reach /.well-known/acme-challenge/ due to a 404, WAF block, or HTTP-to-HTTPS redirect.
• Renamed certificate bug (EXTLETSENC-483) — the SSL It! extension cannot match the certificate to the domain because it was renamed.
• IPv6 DNS mismatch or rate limits — Let's Encrypt follows IPv6 AAAA records to a server that doesn't serve the challenge file, or the domain has hit issuance rate limits.
• Scheduled task not running — the Plesk cron job that triggers renewal has been disabled or is erroring silently.

Fix 1: Enable 'Keep Secured' on the Domain or Service Plan

The most common reason Let's Encrypt stops auto-renewing is that Keep Secured is turned off. This checkbox tells Plesk to automatically reissue the certificate before it expires.

Enable Keep Secured for a single domain

plesk bin extension --exec letsencrypt cli.php --status --domain example.com

Fix 2: Resolve ACME HTTP-01 Challenge Failures (404s, WAF Blocks, Redirects)

Let's Encrypt places a temporary token file at http://yourdomain.com/.well-known/acme-challenge/<token> and its servers fetch that URL to verify domain control. If anything prevents a 200 response, renewal fails.

The error in Plesk SSL It! logs looks like:

ERROR: Failed authorization procedure. example.com (http-01):
urn:ietf:params:acme:error:unauthorized :: Invalid response from
http://example.com/.well-known/acme-challenge/<token>: 404

Test the challenge path manually

TOKEN=$(openssl rand -hex 16)
mkdir -p /var/www/vhosts/example.com/httpdocs/.well-known/acme-challenge
echo "test-$TOKEN" > /var/www/vhosts/example.com/httpdocs/.well-known/acme-challenge/$TOKEN
curl -sv http://example.com/.well-known/acme-challenge/$TOKEN

Fix HTTP-to-HTTPS redirect blocking the challenge

Add a redirect exception in Apache vhost additional directives:

RewriteCond %{REQUEST_URI} !^\/\.well-known\/acme-challenge
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

In Plesk: Websites & Domains → Apache & Nginx Settings → Additional Apache directives for the HTTP virtual host.

Whitelist the challenge path in ModSecurity (WAF)

cat > /etc/httpd/conf.d/modsecurity.d/acme-whitelist.conf <<'EOF'
<LocationMatch "/\.well-known/acme-challenge/">
  SecRuleEngine Off
</LocationMatch>
EOF
plesk bin http_server --reconfigure-all

Fix nginx document root mismatch

location ~ ^/\.well-known/acme-challenge/ {
  root /var/www/vhosts/example.com/httpdocs;
  try_files $uri =404;
  allow all;
}

Fix 3: Correct the Renamed Certificate Bug in SSL It! Extension

Plesk bug EXTLETSENC-483 causes auto-renewal to silently skip certificates that were renamed. The extension expects domain-level certificates to follow this exact naming convention: Lets Encrypt example.com.

Identify renamed certificates

plesk bin certificate --list -admin | grep -v "Lets Encrypt"

Any Let's Encrypt certificate appearing here has been renamed and will not auto-renew.

Reissue with the correct name

# Remove the misnamed certificate
plesk bin certificate --remove "My Old Cert Name" -domain example.com

# Reissue via SSL It!
plesk bin extension --exec letsencrypt cli.php -d example.com -d www.example.com

Fix 4: Diagnose IPv6 DNS and Rate-Limit Issues

IPv6 DNS causing validation failures

Let's Encrypt validation servers use both IPv4 and IPv6. If your domain has a stale AAAA record, IPv6 validation fails even when IPv4 works.

dig AAAA example.com +short

If the returned IPv6 address is not your server's, remove the AAAA record in Plesk: Websites & Domains → DNS Settings.

Rate limit errors

The error in Plesk logs reads:

ERROR: urn:ietf:params:acme:error:rateLimited :: too many failed authorizations recently

Key rate limits: 50 certificates per registered domain per week, 5 failed validation attempts per hostname per hour. Check recent issuances:

curl -s "https://crt.sh/?q=example.com&output=json" |   python3 -c "import sys,json; certs=json.load(sys.stdin);   [print(c['not_before'], c['issuer_name'][:40]) for c in certs[:20]]"

If rate limited, wait for the 7-day sliding window to reset or contact your managed Plesk support team for expedited resolution.

Fix 5: Manually Trigger Renewal and Verify Scheduled Tasks

Check SSL It! extension logs first

ls -lt /usr/local/psa/var/log/letsencrypt-*.log | head -5
tail -200 /usr/local/psa/var/log/letsencrypt-renewal-$(date +%Y-%m-%d).log

Manually trigger renewal

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

Trigger renewal for all domains

plesk bin scheduled_task --run -task-id "letsencrypt_auto_renew"

Or via UI: Tools & Settings → Scheduled Tasks → Let's Encrypt auto-renewal → Run Now.

Verify certificate expiry

openssl s_client -servername example.com -connect example.com:443 </dev/null 2>/dev/null |   openssl x509 -noout -dates -issuer

Set up proactive expiry monitoring

cat > /usr/local/scripts/check-cert-expiry.sh <<'EOF'
#!/usr/bin/env bash
THRESHOLD_DAYS=14
for D in $(plesk db -Ne "SELECT name FROM domains WHERE parentDomainId=0 AND htype='vrt_hst'"); do
  EXPIRY=$(echo | openssl s_client -servername "$D" -connect "$D":443 2>/dev/null |     openssl x509 -noout -enddate 2>/dev/null | cut -d= -f2)
  [[ -z "$EXPIRY" ]] && continue
  EXPIRY_EPOCH=$(date -d "$EXPIRY" +%s)
  DAYS_LEFT=$(( (EXPIRY_EPOCH - $(date +%s)) / 86400 ))
  if [[ $DAYS_LEFT -lt $THRESHOLD_DAYS ]]; then
    echo "$D: $DAYS_LEFT days left (expires $EXPIRY)"
  fi
done
EOF
chmod 700 /usr/local/scripts/check-cert-expiry.sh

FAQs

How often does Plesk try to auto-renew Let's Encrypt certificates?

Plesk checks daily and attempts renewal when the certificate has 30 or fewer days remaining. Let's Encrypt certificates are valid for 90 days, so renewal typically triggers around the 60-day mark. You can also trigger renewal manually using plesk bin extension --exec letsencrypt cli.php -d example.com.

What does "too many failed authorizations recently" mean in Plesk?

Let's Encrypt's servers have attempted and failed the ACME challenge for your domain more than 5 times within the past hour. Each failed renewal attempt counts against this limit. Identify and resolve the root cause first, then wait at least 1 hour before retrying.

Why did my Plesk Let's Encrypt certificate stop renewing after I renamed it?

This is known bug EXTLETSENC-483 in Plesk's SSL It! extension. The auto-renewal scheduler expects domain-level certificates to be named Lets Encrypt example.com exactly. Any other name causes the scheduler to skip it silently. Reissue the certificate through the SSL It! interface to create a new one with the correct name.

Can an IPv6 AAAA record cause Let's Encrypt renewal to fail in Plesk?

Yes. Let's Encrypt validates from both IPv4 and IPv6. If your domain has a stale AAAA record pointing to an IP not configured on your server, IPv6 validation fails. Remove stale AAAA records from your Plesk DNS zone to resolve this.

How do I check if Let's Encrypt rate limits are causing failures?

Query Certificate Transparency logs: curl -s "https://crt.sh/?q=example.com&output=json". If you see more than 50 certificates issued in the past 7 days, you've hit the weekly rate limit. Let's Encrypt rate limits reset on a 7-day sliding window — no action required except waiting.

Conclusion

Plesk Let's Encrypt auto-renewal failures follow predictable patterns. Start with the Keep Secured checkbox, work through ACME challenge verification, check for renamed certificates, audit DNS AAAA records, and confirm the scheduled task is running. Add a daily expiry monitoring cron job to catch future failures before visitors see them. For hands-on managed Plesk SSL maintenance, CloudHouse Technologies handles proactive certificate monitoring and renewal as part of its standard scope.