An SSL certificate that fails to renew in Plesk causes one of the most visible and urgent problems a server admin can face: your websites show a "Your connection is not private" warning in browsers, search engines flag the site as insecure, and visitor trust collapses instantly. The good news is that most Plesk SSL renewal failures follow a predictable pattern with a clear fix. This guide walks you through 7 proven solutions, from the most common causes to advanced CLI-level repairs.
Why Does Plesk SSL Renewal Fail?
Plesk uses Let's Encrypt for free SSL certificates (auto-renewed every 90 days) and also supports paid certificates from other CAs. Renewal failures almost always come from one of these causes:
- DNS validation failure: Let's Encrypt can't verify domain ownership because the domain's DNS doesn't resolve to your server's IP
- .htaccess or Nginx rewrite rules: URL redirect rules intercept the Let's Encrypt HTTP-01 challenge before it can be validated
- Port 80 blocked: Let's Encrypt requires port 80 to be open for HTTP-01 challenge validation
- IPv4/IPv6 mismatch: Your DNS has an AAAA record pointing to an IPv6 address that your server doesn't listen on
- Rate limiting: Let's Encrypt allows only 5 failed renewal attempts per domain per hour — too many retries lock you out temporarily
- Certificate already expired: Plesk auto-renewal runs before expiry, but if the renewal job was skipped, you may have an already-expired cert that needs manual replacement
- Wildcard certificate DNS challenges: Wildcard certs require DNS-01 validation, which fails if your DNS is managed externally and Plesk can't update DNS TXT records automatically
Fix 1: Check and Fix DNS Validation
The most common cause of Let's Encrypt renewal failure in Plesk is a DNS problem. Let's Encrypt needs to confirm that your domain resolves to your server's IP before issuing the certificate.
# Check what IP your domain currently resolves to
dig A yourdomain.com +short
# Verify your server's actual public IP
curl -4 ifconfig.me
If the domain doesn't resolve to your server's IP, the renewal will always fail. Common DNS issues to check:
- Propagation delay: If you recently changed DNS records, wait 10–30 minutes for propagation before retrying
- Proxy/CDN enabled: If your domain is proxied through Cloudflare (orange cloud), the IP Let's Encrypt sees is Cloudflare's, not your server's. Temporarily set the DNS record to DNS-only (grey cloud) during renewal, then re-enable proxying.
- Missing A record: Confirm the domain has an A record pointing to your server in Plesk under Websites & Domains → DNS Settings
Fix 2: Remove .htaccess or Nginx Rewrites Blocking Validation
Let's Encrypt validates domain ownership by placing a challenge file at http://yourdomain.com/.well-known/acme-challenge/ and then fetching it over HTTP. If your .htaccess file or Nginx configuration redirects all HTTP traffic to HTTPS (or rewrites all URLs), this challenge request never reaches the file and validation fails.
For Apache (.htaccess)
Add an exception BEFORE your HTTPS redirect rule:
RewriteEngine On
# Let's Encrypt exception — must come before HTTPS redirect
RewriteRule ^\.well-known/acme-challenge/ - [L]
# Your existing HTTPS redirect
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
For Nginx
In Plesk's Nginx configuration, add a location block for the challenge path:
location /.well-known/acme-challenge/ {
root /var/www/vhosts/yourdomain.com/httpdocs;
allow all;
}
After adding these exceptions, retry the SSL renewal in Plesk.
Fix 3: Fix IPv4/IPv6 Conflicts
If your domain has both an A record (IPv4) and an AAAA record (IPv6), Let's Encrypt may try to validate via the IPv6 address. If your server isn't listening on that IPv6 address, validation fails.
# Check if your domain has AAAA records
dig AAAA yourdomain.com +short
# Check if your server is listening on IPv6
ip -6 addr show
If you have AAAA records but your server doesn't support IPv6, remove the AAAA records from your DNS settings in Plesk under Websites & Domains → DNS Settings. Once removed, Let's Encrypt will only attempt IPv4 validation.
💡 None of these worked? Skip the guesswork.
Get Expert Help →Fix 4: Renew SSL Manually via the Plesk UI
Sometimes the auto-renewal task fails silently. Trigger a manual renewal:
Go to Websites & Domains → your domain → SSL/TLS Certificates.
If a Let's Encrypt certificate is installed, you'll see a Renew button. Click it and Plesk will run the renewal process immediately and show you any error messages in real time.
Plesk's renewal error messages are specific — they'll tell you exactly which validation step failed. Use the error text to target the correct fix from this guide.
Fix 5: Force Renewal via CLI (certbot/plesk)
If the Plesk UI renewal keeps failing, force it from the command line where you get more detailed output:
# Plesk's built-in SSL renewal command
plesk bin extension --exec letsencrypt cli.php -d yourdomain.com -d www.yourdomain.com
# Force renewal with verbose output
plesk bin extension --exec letsencrypt cli.php -d yourdomain.com --force
If Plesk uses the system certbot directly:
# Check certbot status
certbot certificates
# Force renew a specific certificate
certbot renew --cert-name yourdomain.com --force-renewal
# Dry run (tests renewal without actually issuing a cert)
certbot renew --dry-run
The CLI output gives you the full validation log, including exactly which check failed and why — much more detailed than the Plesk UI error message.
Fix 6: Replace with a New Certificate
If renewal is stuck in a broken state (e.g., the old certificate is corrupted or the renewal process is hitting Let's Encrypt rate limits), deleting and re-issuing a fresh certificate often resolves the issue faster than debugging the failed renewal.
In Plesk: Websites & Domains → SSL/TLS Certificates → Remove the existing certificate, then click Get it free to request a new Let's Encrypt certificate from scratch. This starts a clean issuance rather than a renewal and often bypasses stuck renewal states.
If you've hit Let's Encrypt's rate limit (5 failed attempts per hour per domain), wait at least 1 hour before trying again.
Fix 7: Check Port 80 and Firewall Rules
Let's Encrypt HTTP-01 validation requires port 80 to be open and reachable from the internet. Even if your site runs on HTTPS only, Let's Encrypt still needs to reach port 80 to complete the challenge.
# Check if port 80 is open on your server
netstat -tlnp | grep :80
# or
ss -tlnp | grep :80
# Test from outside: check if port 80 is reachable
curl -I http://yourdomain.com/.well-known/acme-challenge/test
If port 80 is blocked, check your firewall:
# CSF firewall — add port 80 to TCP_IN
vi /etc/csf/csf.conf
# Find TCP_IN and ensure 80 is included, then restart:
csf -r
# iptables — open port 80
iptables -I INPUT -p tcp --dport 80 -j ACCEPT
Also check if Plesk's Fail2Ban has blocked Let's Encrypt's IP ranges — check the Fail2Ban logs and whitelist the ACME challenge user-agent if needed.
SSL certificate management across multiple Plesk servers can be time-consuming and error-prone, especially with wildcard certificates and external DNS providers. CloudHouse's managed Plesk support handles SSL issuance, renewal monitoring, and emergency fixes — so you never face an expired certificate again.