Plesk SSL Certificate Not Renewing? Fix Let's Encrypt ACME, Rate Limits & Chain Errors (2026)

Why Plesk SSL Certificates Fail to Renew

A Plesk server that stops renewing SSL certificates creates cascading failures: browsers show scary "Your connection is not private" warnings, search engines penalise sites with expired certificates, and HTTPS-dependent services (APIs, payment gateways, mail submission on port 587) break outright. The frustrating part is that Plesk's Let's Encrypt extension is supposed to handle renewals automatically — yet renewal failures are among the most common Plesk support tickets in 2025–2026.

This guide covers every failure mode: ACME HTTP-01 and DNS-01 challenge failures, rate limit errors, certificate chain issues, external DNS complications, Plesk panel certificate expiry, and manual fallback procedures.

Understanding How Plesk SSL Renewal Works

Plesk uses the SSL It! extension (built on Certbot and the ACME v2 protocol) to issue and renew Let's Encrypt certificates. Renewal is triggered by a background task called Let's Encrypt certificate renewal that runs nightly via Plesk's task scheduler.

The renewal process has two challenge modes:

• HTTP-01 (default): Let's Encrypt makes an HTTP request to http://yourdomain.com/.well-known/acme-challenge/TOKEN. Your server must respond with a specific key value.
• DNS-01: Let's Encrypt checks for a TXT record at _acme-challenge.yourdomain.com. Required for wildcard certificates.

If either challenge fails, the certificate is not renewed and you get an error in Websites & Domains > SSL/TLS Certificates.

Step 1: Check the SSL/TLS Certificate Status in Plesk

Navigate to Websites & Domains > [domain] > SSL/TLS Certificates. Look for:

• Red "Expired" badge — certificate already expired
• Yellow warning — certificate expires within 30 days
• Error message from the last renewal attempt

Click the certificate name to see the full error. Common messages:

• Error: Failed to verify the domain. Server returned HTTP 403
• Error: Connection refused on port 80
• Error: DNS problem: NXDOMAIN looking up A for _acme-challenge...
• Error: too many certificates already issued for this domain
• Error: The certificate chain is incomplete

Step 2: Fix HTTP-01 Challenge Failures (Port 80 Blocked)

The most common Let's Encrypt failure: port 80 is blocked by a firewall, or HTTP is redirected to HTTPS before the ACME challenge can be served.

Test Port 80 Accessibility

# From your Plesk server, test external port 80
curl -I http://yourdomain.com/.well-known/acme-challenge/test

# From a different machine or via online tool:
# https://www.site24x7.com/tools/port-checker.html

# Check what is listening on port 80
ss -tlnp | grep ':80'

Fix: Firewall Blocking Port 80

# Plesk Firewall (if using Plesk firewall module)
# Plesk > Tools & Settings > Firewall > Add Custom Rule
# Allow TCP port 80 from any source

# iptables (manual)
iptables -I INPUT -p tcp --dport 80 -j ACCEPT
iptables-save > /etc/iptables/rules.v4

# CSF firewall
nano /etc/csf/csf.conf
# Ensure TCP_IN includes port 80
# TCP_IN = "20,21,22,25,53,80,110,143,443,587,993,995,2222,8443,8880"
csf -r

Fix: HTTPS Redirect Blocking ACME Challenge

If Apache or nginx forces all HTTP to HTTPS before serving /.well-known/acme-challenge/, the challenge file is never served. Add an exception:

# Apache: add to VirtualHost :80 config
# /etc/httpd/conf.d/yourdomain.com.conf
<VirtualHost *:80>
    Alias /.well-known/acme-challenge/ /var/www/vhosts/yourdomain.com/httpdocs/.well-known/acme-challenge/
    <Directory "/var/www/vhosts/yourdomain.com/httpdocs/.well-known/acme-challenge/">
        Options None
        AllowOverride None
        Require all granted
    </Directory>
    # Other directives...
    RewriteEngine On
    RewriteCond %{REQUEST_URI} !^/.well-known/acme-challenge/
    RewriteRule ^(.*)$ https://%{HTTP_HOST}$1 [R=301,L]
</VirtualHost>

In Plesk, you can add this in Websites & Domains > Apache & nginx Settings > Additional Apache directives for HTTP.

Step 3: Fix DNS-01 Challenge for Wildcard Certificates

Wildcard certificates (*.yourdomain.com) require DNS-01 challenge. This fails when:

• Plesk is not the authoritative DNS server for the domain
• External DNS provider API credentials are wrong or expired
• DNS propagation delay exceeds Let's Encrypt's verification window

Configure External DNS API in Plesk

# Plesk supports automatic DNS-01 via these providers:
# Cloudflare, Route53, DigitalOcean, Gandi, Linode, etc.

# For Cloudflare: get your Zone API Token (not Global API Key)
# Plesk > Extensions > SSL It! > Settings > DNS providers > Add Cloudflare

# Verify the TXT record was created:
dig TXT _acme-challenge.yourdomain.com +short @8.8.8.8

Manual DNS-01 Fallback

If API integration fails, issue the certificate manually:

# Install certbot if not present
apt-get install certbot    # Debian/Ubuntu
yum install certbot        # CentOS/RHEL

# Request with manual DNS challenge
certbot certonly --manual --preferred-challenges dns   -d "*.yourdomain.com" -d "yourdomain.com"

# Certbot will ask you to create a TXT record:
# _acme-challenge.yourdomain.com = "VERIFICATION_TOKEN"
# Add it in your DNS provider, wait for propagation, then press Enter

# After success, find the cert at:
ls /etc/letsencrypt/live/yourdomain.com/

Step 4: Fix Rate Limit Errors

Let's Encrypt limits issuance to 50 certificates per registered domain per week and 5 duplicate certificates per week. If you hit the limit:

# Error example:
# Error: too many certificates already issued for exact set of domains

# Check current certificate count at:
# https://crt.sh/?q=yourdomain.com

# Rate limit details: https://letsencrypt.org/docs/rate-limits/

Solutions when rate-limited:

1. Wait — limits reset after 7 days from the earliest issuance
2. Use a wildcard — one wildcard cert covers all subdomains, using only one certificate slot
3. Combine SANs — one certificate with multiple domains in the SAN field uses one slot
4. Use a paid certificate — no rate limits; upload via Plesk SSL/TLS Certificates > Upload

Step 5: Fix Incomplete Certificate Chain Errors

Browsers may show "NET::ERR_CERT_AUTHORITY_INVALID" even when the certificate itself is valid, because the intermediate chain is missing.

# Verify the full chain on your server
openssl verify -CAfile /etc/ssl/certs/ca-certificates.crt /etc/letsencrypt/live/yourdomain.com/cert.pem

# Check what Plesk is serving
echo | openssl s_client -connect yourdomain.com:443 -showcerts 2>/dev/null | grep -A2 "Certificate chain"

# The chain should show 2-3 certificates:
#  0 = your domain certificate
#  1 = Let's Encrypt intermediate (R10 or E5)
#  2 = ISRG Root X1 (optional in modern configs)

Fix Chain in Plesk

In Plesk, go to Websites & Domains > SSL/TLS Certificates > [certificate] > Edit. In the CA Certificate field, paste the full Let's Encrypt chain (R10 intermediate + root). Download the current chain from:

# Download current Let's Encrypt chain
curl -O https://letsencrypt.org/certs/lets-encrypt-r10.pem
curl -O https://letsencrypt.org/certs/isrgrootx1.pem
cat lets-encrypt-r10.pem isrgrootx1.pem > fullchain.pem

Step 6: Renew the Plesk Panel SSL Certificate

The Plesk admin panel itself (port 8443) has its own SSL certificate, separate from website certificates. When this expires, you see "Your connection is not private" when accessing the panel at https://yourserver:8443.

# Renew Plesk panel certificate via CLI
plesk bin certificate --renew-panel-certificate

# Or via plesk installer
plesk installer --update-release

# Check current panel cert expiry
openssl s_client -connect localhost:8443 < /dev/null 2>/dev/null | openssl x509 -noout -dates

# Force Plesk to reissue its self-signed cert if Let's Encrypt fails:
plesk bin certificate --self-signed -create -domain yourdomain.com

To use a Let's Encrypt certificate for the Plesk panel:

1. Go to Tools & Settings > SSL/TLS Certificates
2. Click Add SSL/TLS Certificate
3. Select Let's Encrypt, enter the server hostname
4. After issuance, go to Tools & Settings > Plesk and select the new certificate as Panel Certificate

Step 7: Fix External DNS Complications

If you use external DNS (Cloudflare, Route53, etc.) and Plesk is not the DNS master, HTTP-01 challenges may fail because:

• Cloudflare's proxy (orange cloud) may intercept the challenge request
• DNS records take time to propagate

# Temporarily set Cloudflare to DNS-only (grey cloud) for the domain
# Then retry Let's Encrypt issuance in Plesk

# Or check if Cloudflare is proxying:
curl -I http://yourdomain.com/.well-known/acme-challenge/test
# Look for "CF-RAY" header — if present, Cloudflare is proxying

# Verify DNS resolution bypassing Cloudflare:
dig yourdomain.com @8.8.8.8 +short
# Should return your actual server IP, not Cloudflare's 104.x.x.x range

Step 8: Force a Manual Certificate Renewal

After fixing the root cause, force immediate renewal without waiting for the nightly task:

# Via Plesk CLI
plesk ext sslit --update -domain yourdomain.com

# Via SSL It! extension web UI
# Websites & Domains > yourdomain.com > SSL/TLS Certificates > Renew

# Via Certbot (if Plesk uses system certbot)
certbot renew --force-renewal -d yourdomain.com

# Check renewal logs
tail -100 /var/log/plesk/panel.log | grep -i "ssl\|certif\|letsencrypt"
tail -100 /var/log/letsencrypt/letsencrypt.log

Step 9: Set Up Automated Renewal Monitoring

Prevent future surprises by monitoring certificate expiry proactively:

# Add a cron job to email you 30 days before expiry
echo "0 6 * * * root openssl s_client -connect yourdomain.com:443 < /dev/null 2>/dev/null | openssl x509 -noout -checkend 2592000 || echo 'SSL expiring in 30 days on yourdomain.com' | mail -s 'SSL WARNING' admin@yourdomain.com" >> /etc/cron.d/ssl-check

# Or use the Plesk built-in notification:
# Tools & Settings > Notifications > add "SSL certificate is about to expire" alert

Conclusion

Plesk SSL certificate renewal failures follow a predictable pattern: port 80 blocked, ACME challenge path intercepted, external DNS misconfiguration, or rate limit exhaustion. Working through this guide in order — check port 80 first, then the challenge path, then DNS configuration — resolves the vast majority of cases. If you manage multiple Plesk servers and want SSL renewals handled automatically with zero downtime, the team at CloudHouse server management monitors and maintains SSL certificates across your entire infrastructure as part of our managed hosting plans.