If Plesk suddenly refuses to issue or renew a Let's Encrypt certificate with the message "too many failed authorizations recently", the panel itself isn't broken — you've hit a rate limit enforced directly by Let's Encrypt's servers. This guide explains exactly what triggers the limit, why waiting alone often isn't enough, and how to fix the underlying validation failure so it doesn't happen again on the next renewal cycle.
What This Error Actually Means
Let's Encrypt enforces a "Failed Validation" limit: a maximum of 5 failed domain validation attempts per account, per hostname, within a rolling one-hour window. Once you hit that limit, every further request for the same domain is rejected immediately with this exact error message, regardless of whether the underlying issue has since been fixed.
Crucially, this limit is enforced on Let's Encrypt's side, not Plesk's. There's no admin toggle, no panel setting, and no support ticket to Plesk that can reset it. The only two ways forward are waiting out the one-hour window, or fixing the root cause so the very next attempt succeeds instead of adding a sixth failure to the count.
Why Validation Keeps Failing in the First Place
The error itself is a symptom — the real problem is whatever is causing the domain validation (ACME challenge) to fail repeatedly before the rate limit kicks in. The most common root causes on Plesk servers are:
- DNS-01 challenge misconfiguration — the CNAME or TXT record required for DNS validation is missing, has a typo, or wasn't propagated before Plesk attempted validation
- Expired or drifted DNS provider API credentials — if you're using Plesk's DNS provider extensions (Cloudflare, Route 53, etc.) for automated DNS-01 challenges, an expired API token silently fails every attempt
- HTTP-01 challenge blocked — a firewall, WAF, or CDN in front of the domain is blocking or redirecting requests to
/.well-known/acme-challenge/ - Domain doesn't actually resolve to this server — a DNS A/AAAA record pointing elsewhere, common right after a migration or DNS change that hasn't fully propagated
- A scheduled renewal task stuck in a retry loop — cron-triggered re-issuance running every few minutes against the same broken domain, burning through the failure quota fast
Step 1: Confirm You're Actually Rate-Limited
Check the Plesk SSL/TLS Certificates log for the domain in question:
tail -100 /usr/local/psa/var/modules/letsencrypt/letsencrypt.logLook for the literal text "too many failed authorizations recently" alongside a timestamp. If the most recent failure was over an hour ago, the rate limit window has already reset and the error you're seeing is a stale cached message — clear it by attempting issuance again after confirming the fix below.
💡 None of these worked? Skip the guesswork.
Get Expert Help →Step 2: Stop the Retry Loop Immediately
1. Disable automatic renewal for the affected domain temporarily.
Go to Domains > example.com > SSL/TLS Certificates and turn off "Renew certificate automatically" while you diagnose the issue. If the Let's Encrypt extension is retrying every few minutes, leaving auto-renewal on will keep re-adding failures to the one-hour count and reset your wait timer.
2. Check the extension's task queue.
plesk bin extension --list-hooks
crontab -l | grep letsencryptConfirm there isn't a duplicate cron entry or a stuck scheduled task hammering the same domain repeatedly.
Step 3: Diagnose the Actual Validation Failure
If Using HTTP-01 Validation
Test that the challenge path is reachable from the public internet, exactly as Let's Encrypt's servers would see it:
curl -I http://example.com/.well-known/acme-challenge/testA 404 is fine (the test file doesn't exist) — what you're checking for is that the request isn't being blocked, redirected to HTTPS before it can complete, or intercepted by a CDN/WAF rule that returns a challenge page instead of passing the request through.
If Using DNS-01 Validation
Confirm the required TXT record actually exists and has propagated:
dig TXT _acme-challenge.example.com @8.8.8.8If nothing returns, the DNS provider integration in Plesk's Let's Encrypt extension isn't writing the record correctly — check the API credentials configured under Tools & Settings > SSL/TLS Certificates > Let's Encrypt settings and re-authenticate if the token has expired.
If the Domain Recently Migrated
Verify the domain's A record actually points to this server's IP:
dig A example.com +shortIf it still resolves to an old server or a DNS caching layer that hasn't updated, validation will fail every time no matter how many times you retry — this is a DNS propagation issue, not a Plesk or Let's Encrypt bug.
Step 4: Use the Staging Environment to Test the Fix
Once you believe the root cause is fixed, don't burn another production attempt to find out. Let's Encrypt's staging environment has dramatically higher rate limits and issues untrusted test certificates specifically for this purpose:
plesk bin extension --exec letsencrypt cli.php -d example.com --stagingIf the staging request succeeds, your validation path is fixed and it's safe to move to production issuance. If it still fails, you have confirmation the root cause hasn't been resolved yet — without spending any of your limited production attempts.
Step 5: Wait Out the Window if Needed
If you can't identify a fixable misconfiguration and the domain genuinely just needs a fresh attempt, the failed authorization limit resets one hour after the first failure in the current window. Set a calendar reminder rather than repeatedly retrying — each retry against still-broken validation adds to the count and can extend how long you're stuck.
Step 6: Re-Issue the Certificate
Once the underlying issue is fixed and the rate limit window has cleared, re-issue normally from Domains > example.com > SSL/TLS Certificates > Get a free certificate from Let's Encrypt, then re-enable automatic renewal.
Understanding Let's Encrypt's Broader Rate Limit Structure
The failed authorization limit is just one of several rate limits Let's Encrypt enforces, and understanding how they interact helps avoid stacking multiple lockouts on top of each other. The main limits relevant to a Plesk admin are:
- Failed Validation limit — 5 failures per account, per hostname, per hour (the one covered in this guide)
- Certificates per Registered Domain — a cap on how many certificates can be issued for the same registered domain within a rolling week, which can also block issuance with a similarly worded error
- Duplicate Certificate limit — a cap on issuing an identical certificate (same exact set of hostnames) repeatedly, often triggered by scripts that re-request the same certificate on every run instead of checking if a valid one already exists
If your Plesk logs mention "too many certificates already issued for exact set of domains" rather than "too many failed authorizations," you're hitting a different limit entirely — the fix there is to stop re-issuing unnecessarily rather than fixing a validation failure, and the reset window is measured in days rather than hours.
A Real Troubleshooting Walkthrough
Consider a Plesk server hosting a client site that recently moved behind Cloudflare for CDN and DDoS protection. Automatic Let's Encrypt renewal fired as scheduled, but Cloudflare's proxy was intercepting the HTTP-01 challenge request and returning a Cloudflare error page instead of passing it through to the origin server. Plesk retried the renewal three times within twenty minutes — following its own built-in retry logic — before Let's Encrypt's failed authorization limit kicked in and blocked further attempts for the hour.
The fix in this case wasn't waiting it out — it was switching to DNS-01 validation (which doesn't depend on the HTTP challenge path being reachable through the CDN) or temporarily setting the DNS record to "DNS only" in Cloudflare during the renewal window. Once the validation method was corrected, the very next attempt succeeded without needing to wait out the full rate-limit window, since enough time had already passed since the last failure.
Checking Plesk's Built-In Retry Behavior
Plesk's Let's Encrypt extension has its own internal retry logic that can compound the problem if left unchecked. Review the extension's configuration to confirm how aggressively it retries on failure:
plesk bin extension --exec letsencrypt cli.php --helpIf the extension is configured to retry immediately rather than backing off, and your validation issue takes more than a few minutes to fix, it's worth disabling automatic retries entirely until the root cause is confirmed resolved — reissuing manually once, successfully, is far better than five automated failures in a row.
Preventing This From Recurring
- Monitor certificate expiry proactively so renewals aren't happening at the last minute under time pressure
- Keep DNS provider API credentials for automated DNS-01 challenges refreshed and monitored for expiry
- Avoid placing a WAF or CDN in front of a domain's
/.well-known/acme-challenge/path, or add an explicit allow rule for it - After any DNS or migration change, confirm propagation with
digbefore triggering a renewal - Test configuration changes against the Let's Encrypt staging environment before touching production certificates
The "too many failed authorizations recently" error is Let's Encrypt protecting its infrastructure from repeated bad requests, not a Plesk malfunction. The fastest path back to a valid certificate is almost always fixing the DNS or HTTP challenge issue causing the failures — not repeatedly clicking retry. If SSL renewal issues like this are a recurring headache across your Plesk fleet, our CloudHouse server management service handles certificate monitoring and DNS validation health checks as part of routine maintenance, so expired credentials and propagation issues get caught before they turn into rate-limit lockouts.