You’ve just completed a cPanel server migration. The accounts are transferred, DNS is propagating, everything looks good… until you check the AutoSSL logs and see this staring back at you:
WARN AutoSSL failed to create a new certificate order because the server's
Let's Encrypt account (https://acme-v02.api.letsencrypt.org/acme/acct/XXXXXXX)
has reached a rate limit.
(429 urn:ietf:params:acme:error:rateLimited)
Every domain on your server needs a fresh SSL certificate simultaneously, and you’ve just burned through Let’s Encrypt’s rate limits in one devastating AutoSSL run. Your clients are seeing browser security warnings. Your inbox is filling up. And there isn’t a single cPanel guide that covers what to do next.
I’ve dealt with this exact scenario multiple times, and the recovery process is surprisingly methodical once you understand the mechanics. This post covers why it happens, how to recover from it right now, and how to prevent it on your next migration.
Why Migrations Trigger the Rate Limit Avalanche
Under normal server operations, AutoSSL certificate renewals are naturally staggered. Certificates were issued at different times, so they expire at different times, and AutoSSL handles them in small batches over weeks and months. The rate limits are essentially invisible.
A migration destroys that staggering completely.
When accounts land on a new server, the existing SSL certificates either don’t transfer at all (common with Let’s Encrypt certs tied to the old server’s ACME account) or they arrive but AutoSSL sees them as foreign certificates needing replacement. The result is the same: AutoSSL queues up every domain on the server for immediate certificate issuance on its next run.
If you’re running a server with 80+ domains (counting www variants, subdomains, mail subdomains, and webmail subdomains), you can easily hit 200–400+ certificate requests in a single AutoSSL pass. That’s catastrophic against Let’s Encrypt’s rate limits.
Understanding the Actual Rate Limits
Let’s Encrypt overhauled their rate limiting infrastructure in early 2025, moving from a rigid weekly window to a token-bucket algorithm that provides more flexibility. Here’s what matters for post-migration recovery:
New Orders per Account: Up to 300 new orders can be created per account every 3 hours, refilling at a rate of 1 order every 36 seconds. For most single-server migrations, this isn’t the limit you’ll hit first.
New Certificates per Registered Domain: This is the one that bites hardest. Each registered domain (the eTLD+1, so example.com regardless of how many subdomains you have) has its own issuance cap. Under the new token-bucket model, the limits refill gradually rather than resetting after a fixed window.
Failed Authorization Limit: Up to 5 authorization failures per hostname per account per hour, refilling at 1 per 12 minutes. This is the silent killer. When AutoSSL attempts to validate domains that aren’t yet pointing to your new server (DNS still propagating), each failure counts against you, compounding the problem.
Duplicate Certificate Limit: If you’re requesting the exact same set of hostnames you already have a valid cert for, there’s a separate limit of 5 duplicate certificates per week.
The key insight: under the old system, hitting the limit meant you were locked out for up to a week. The new token-bucket approach means your capacity refills continuously, which actually makes recovery faster, if you approach it strategically.
Immediate Triage: The First 30 Minutes
When you discover you’ve hit the rate limit, stop and assess before doing anything else.
Step 1: Stop AutoSSL from Making Things Worse
The single most important action is preventing AutoSSL from running again and burning through whatever capacity you’re regaining. Log into WHM and navigate to Home → SSL/TLS → Manage AutoSSL. Under the Manage Users tab, temporarily disable AutoSSL for all users by selecting them all and clicking Disable AutoSSL on selected users.
Alternatively, via SSH as root:
# Disable the AutoSSL cron temporarily
/usr/local/cpanel/scripts/set_autossl_metadata --notify-only=1
This tells cPanel to run AutoSSL in notification-only mode. It will check and report but not attempt to issue any certificates.
Step 2: Audit Your Current SSL State
You need to know exactly where things stand. Run this to get a snapshot:
# Count total domains needing certificates
whmapi1 get_autossl_pending_queue | grep -c 'domain'
# Check current certificate status across all accounts
for user in $(ls /var/cpanel/users); do
echo "=== $user ==="
/usr/local/cpanel/bin/autossl_check --user=$user --notify-only 2>&1 | grep -E "(rate limit|DCV|certificate)"
done
Step 3: Identify What Actually Needs SSL Right Now
Not every domain on your server is equally urgent. Categorize them:
- Critical: Production websites with active traffic and e-commerce
- Important: Active sites with regular visitors
- Can wait: Parked domains, unused subdomains, development sites
- Exclude entirely: Domains not pointed to this server yet, legacy domains with no content
This prioritization is the foundation of your recovery strategy.
The Recovery Strategy: Controlled Batch Issuance
Here’s the process that cPanel’s documentation never covers: how to systematically work through hundreds of domains without repeatedly slamming into rate limits.
Phase 1: Clean Up the Dead Weight
Before you issue a single certificate, reduce the total number of domains AutoSSL needs to process.
Exclude domains that don’t need AutoSSL:
In WHM under Manage AutoSSL → Manage Users, or at the cPanel account level under SSL/TLS Status, exclude:
- Subdomains that don’t serve any content (cPanel auto-creates
cpanel.,webmail.,webdisk.,mail.,cpcalendars.,cpcontacts.subdomains for every account) - Parked/aliased domains with no real traffic
- Domains whose DNS hasn’t propagated to the new server yet (these will fail DCV and waste your failure quota)
Via command line, you can check which domains are actually resolving to your server:
SERVER_IP=$(hostname -I | awk '{print $1}')
for domain in $(whmapi1 get_autossl_pending_queue | grep 'domain:' | awk '{print $2}'); do
RESOLVED=$(dig +short $domain A | tail -1)
if [ "$RESOLVED" != "$SERVER_IP" ]; then
echo "NOT POINTED: $domain -> $RESOLVED"
fi
done
Every domain you exclude is one fewer certificate request eating into your rate limit budget.
Disable unnecessary subdomains server-wide:
If your server’s AutoSSL settings include the service subdomains (cpanel., webmail., etc.), consider whether you really need individual certs for all of them. Many admins find they can exclude these from AutoSSL without any real impact, especially if the main domain and www variant are covered.
Phase 2: Batch Issuance by Priority
Now, re-enable AutoSSL selectively. Instead of turning it on for all users at once, process them in controlled batches.
Create a batch script:
#!/bin/bash
# batch_autossl.sh - Process AutoSSL in controlled batches
# Usage: ./batch_autossl.sh userlist.txt
BATCH_SIZE=10
WAIT_MINUTES=15
BATCH_NUM=0
while IFS= read -r user; do
BATCH_NUM=$((BATCH_NUM + 1))
echo "[$(date)] Processing batch item $BATCH_NUM: $user"
# Run AutoSSL for this specific user
/usr/local/cpanel/bin/autossl_check --user="$user" 2>&1 | tee -a /var/log/autossl_recovery.log
# Every BATCH_SIZE users, pause to let the token bucket refill
if [ $((BATCH_NUM % BATCH_SIZE)) -eq 0 ]; then
echo "[$(date)] Batch of $BATCH_SIZE complete. Waiting $WAIT_MINUTES minutes..."
sleep $((WAIT_MINUTES * 60))
fi
done < "$1"
echo "[$(date)] All batches complete."
Create your prioritized user list:
# Start with your highest-priority accounts
cat > /root/autossl_priority.txt << 'EOF'
hightraffic_user1
ecommerce_user2
business_user3
EOF
# Then add remaining users
cat > /root/autossl_remaining.txt << 'EOF'
blog_user4
personal_user5
parked_user6
EOF
Run the priority batch first:
chmod +x batch_autossl.sh
./batch_autossl.sh /root/autossl_priority.txt
The key variables to tune are BATCH_SIZE and WAIT_MINUTES. With the token-bucket refill rate of 1 new order every 36 seconds, a 15-minute pause between batches of 10 users gives you roughly 25 orders of headroom, enough for most accounts with a handful of domains each. If your accounts have many domains (10+ each), reduce the batch size or increase the wait time.
Phase 3: Monitor and Adjust
Watch the AutoSSL logs in real time as your batches process:
tail -f /var/log/autossl_recovery.log
# Also check the cPanel AutoSSL log
tail -f /var/cpanel/logs/autossl.log
If you see rate limit errors reappearing, increase the wait time between batches. If everything is going through clean, you can cautiously decrease it.
Phase 4: Re-enable Normal AutoSSL Operation
Once all priority accounts have certificates, re-enable AutoSSL for the full server:
/usr/local/cpanel/scripts/set_autossl_metadata --notify-only=0
The remaining lower-priority domains will be picked up on the normal AutoSSL schedule (typically runs every 24 hours for each user), and since you’ve already handled the bulk of the work, the natural staggering will keep you well within rate limits.
The Alternative Provider Escape Hatch
Here’s something most admins don’t consider: you don’t have to use Let’s Encrypt for your immediate recovery.
Temporarily switch to the cPanel (Sectigo) provider:
If your cPanel license includes the default Sectigo-powered AutoSSL provider, you can switch to it in WHM under Manage AutoSSL → Providers. Sectigo has its own, separate rate limits, and switching providers gives you a completely fresh rate-limit budget. Use Sectigo to cover your critical domains immediately, then switch back to Let’s Encrypt once the rate limit pressure has subsided.
The trade-off: cPanel/Sectigo certificates have a 90-day validity just like Let’s Encrypt, but the issuance limits are tied to your cPanel license rather than a public rate limit. For a migration recovery scenario, this can be a lifesaver.
Use a different ACME account:
If you must stick with Let’s Encrypt, resetting your ACME registration in WHM (Manage AutoSSL → Providers → Let’s Encrypt → Reset Registration) creates a new account. The new-orders-per-account limit is per account, so this effectively resets that specific counter. Note that the per-registered-domain limits still apply regardless of account, since they track by domain, not by ACME account, so this only helps if you were specifically hitting the per-account order limit.
Pre-Migration Checklist: Preventing This Next Time
The best recovery strategy is not needing one. Here’s what to do before your next migration:
1. Transfer certificates along with accounts. When using WHM’s Transfer Tool or pkgacct/restorepkg, SSL certificates are typically included in the backup. Verify they actually restored:
# After migration, check for valid certs
for user in $(ls /var/cpanel/users); do
whmapi1 get_autossl_check_schedule --username=$user
done
2. Stagger account migrations over multiple days. Instead of migrating 100 accounts in one shot, do 20–30 per day. This naturally distributes the AutoSSL certificate requests.
3. Pre-exclude non-essential subdomains. Before the migration, document which service subdomains (cpanel., webmail., webdisk.) your clients actually use. Exclude the rest from AutoSSL on the new server before restoring accounts.
4. Verify DNS propagation before enabling AutoSSL. Use a script to confirm domains resolve to the new server’s IP before allowing AutoSSL to attempt validation. Failed DCV attempts waste your authorization failure budget.
# dns_check_pre_autossl.sh
SERVER_IP="YOUR.NEW.SERVER.IP"
for domain in $(cat /root/migrated_domains.txt); do
CURRENT=$(dig +short $domain @8.8.8.8 A | tail -1)
if [ "$CURRENT" = "$SERVER_IP" ]; then
echo "READY: $domain"
else
echo "WAITING: $domain (currently -> $CURRENT)"
fi
done
5. Disable AutoSSL before restoring accounts. Set AutoSSL to notification-only mode before you begin restoring cPanel backups. Only re-enable it after all accounts are restored and you’ve implemented your batching strategy.
6. Keep a secondary provider configured. Having the cPanel/Sectigo provider ready as a fallback means you can always switch if Let’s Encrypt rate limits become a problem.
Quick Reference: Rate Limit Error Decoder
When you see rate limit errors in the AutoSSL log, here’s what each one means and how long you need to wait:
| Error Pattern | What It Means | Recovery |
|---|---|---|
rateLimited (new orders) |
Too many certificate requests from this ACME account | Refills at ~1 order/36 seconds; wait 15–30 min between batches |
rateLimited (certificates per domain) |
Too many certs issued for this registered domain | Refills gradually under token bucket; space out requests over hours |
rateLimited (failed authorizations) |
Too many failed DCV attempts for a hostname | Refills at 1 per 12 min per hostname; fix DNS/server issues first |
rateLimited (duplicate certificate) |
Exact same cert (same hostnames) issued too many times | Wait or change the hostname set slightly |
rateLimited (new accounts) |
Too many ACME accounts from this IP | Refills at 1 account/22 sec; rarely hit in migration scenarios |
Final Thoughts
The post-migration AutoSSL rate limit crunch is one of those problems that hits hardest when you’re already stressed from a migration. The fact that cPanel’s documentation doesn’t address this specific scenario (as of this writing) makes it even more frustrating.
The core recovery playbook is straightforward: stop the bleeding by disabling AutoSSL, triage your domains by priority, exclude everything non-essential, and batch your way back to full coverage. Combined with the pre-migration prevention steps, you should never have to spend a week watching SSL errors scroll by again.