How to Fix AutoSSL Errors in cPanel: Common Problems and Solutions

by

If you run a cPanel server, you’ve probably encountered AutoSSL errors at some point. AutoSSL is one of cPanel’s most useful features — it automatically provisions and renews free SSL/TLS certificates from Sectigo (formerly Comodo) or Let’s Encrypt, keeping your sites secure without manual intervention. But when it breaks, visitors see browser security warnings, email delivery can fail, and search engines may penalize your sites for not serving content over HTTPS.

The good news is that most AutoSSL errors are straightforward to diagnose and fix. Whether you’re seeing “AutoSSL Check Failed,” “Order Failed,” or a certificate that simply won’t install, this guide walks through every common error scenario and the exact steps to resolve it. We’ll cover server-level checks, DNS validation issues, rate limiting, and preventive configuration so AutoSSL stays healthy going forward.

Understanding How AutoSSL Works in cPanel

Before diving into troubleshooting, it helps to understand the flow. cPanel’s AutoSSL runs as a periodic system task — typically every few hours — that checks every domain on the server against a set of rules:

  1. Does the domain already have a valid SSL certificate that won’t expire soon?
  2. Is the domain pointed to this server (DNS resolves to the server’s IP)?
  3. Does the domain pass HTTP-01 or DNS-01 validation with the certificate authority?
  4. If yes, AutoSSL requests, installs, and activates the new certificate.

AutoSSL uses Sectigo as its default certificate authority on most cPanel installations, with Let’s Encrypt as an alternative. You can switch between them in WHM → Manage AutoSSL. The entire process is designed to be hands-off — /scripts/run_autossl is the command that triggers it manually if you need to force a check.

Common AutoSSL Errors and How to Fix Them

AutoSSL Check Failed — “Could Not Verify Domain Ownership”

This is the most frequent AutoSSL error. It means the certificate authority couldn’t confirm you control the domain. Here’s how to troubleshoot:

  1. Verify DNS resolution. Run dig +short example.com from the command line. The result must point to the server’s public IP address. If it doesn’t, update your DNS A record through your domain registrar.
  2. Check that the website loads over HTTP. Since AutoSSL uses HTTP-01 validation by default, the CA needs to access http://example.com/.well-known/pki-validation/... on port 80. Visit http://example.com in a browser — if it redirects to HTTPS before AutoSSL can complete the validation, the check will fail. Temporarily disabling the HTTPS redirect via .htaccess or your CMS can help confirm this is the issue.
  3. Confirm the domain isn’t behind a proxy (Cloudflare). If you use Cloudflare proxying (the orange cloud), HTTP-01 validation may fail because the CA sees Cloudflare’s IP instead of your server’s. The fix is to either pause Cloudflare proxying (set to DNS-only / gray cloud) for the duration of the certificate validation, or switch AutoSSL to DNS-01 validation via WHM if your DNS provider supports it.

AutoSSL Order Failed — Rate Limited or Certificate Limit Reached

Both Sectigo and Let’s Encrypt enforce rate limits. If you’re seeing “Order Failed” with no further explanation, rate limiting is the likely culprit:

  • Let’s Encrypt limits: 50 certificates per registered domain per week, 300 pending orders per account, and 5 failed validation attempts per hour per domain. If you frequently retry, you’ll hit these quickly.
  • Sectigo limits: 1 certificate per domain per 24 hours during validation failures. Repeated attempts within that window will fail.

Fix: Wait. Most AutoSSL rate limits reset within 24 hours. After the cooldown, run /scripts/run_autossl --force from the command line as the root user. To prevent future rate limiting, ensure DNS is correct before retrying — don’t hammer the CA with requests until you’ve fixed the underlying issue.

Certificate Installed but Browser Shows “Not Secure”

This usually isn’t an AutoSSL failure — it’s a configuration issue. Common causes:

  • Mixed content: Your site loads resources (images, scripts, stylesheets) over HTTP instead of HTTPS. Use a plugin like “Really Simple SSL” for WordPress, or update hardcoded URLs in your database.
  • Invalid certificate chain: The server isn’t serving the intermediate certificate. In WHM → Service Configuration → Apache Configuration → Include Editor, check that SSLCertificateChainFile points to the correct bundle. On cPanel 98+, this is managed automatically but can be overridden.
  • Default vs. dedicated IP: If multiple domains share an IP and SNI isn’t supported by the visitor’s browser (very rare today), the wrong certificate may be served.

Run openssl s_client -connect example.com:443 -servername example.com to verify the certificate chain is complete and matches the requested domain.

AutoSSL Status Shows “Pending” or “Waiting” Indefinitely

When AutoSSL stays in a pending state for more than a few hours, the issue is often one of these:

  • DNS propagation delay. If you recently changed DNS records, wait 24–48 hours for full propagation. Use whatsmydns.net to check global propagation status.
  • Firewall blocking validation requests. The CA servers need to reach port 80 on your server. Check your server firewall (CSF, iptables, or cloud firewall) to ensure HTTP traffic isn’t blocked or restricted to specific IPs.
  • cPanel mail SNI mismatch. In rare cases, the SSL certificate for mail services (imap.example.com, smtp.example.com) isn’t covered by the domain certificate. WHM → Service Manager can help verify which services have valid certificates.

Quick fix: Run /scripts/run_autossl --force --verbose and watch the output. It will show exactly where the process stalls, giving you a direct clue about what to fix.

How to Check AutoSSL Logs for Detailed Diagnosis

AutoSSL writes detailed logs that are invaluable when standard checks don’t reveal the problem:

# View the most recent AutoSSL log
/scripts/run_autossl --log

# Read the full log file
cat /var/log/cpanel/autossl.log

# Tail it in real-time while running a manual check
tail -f /var/log/cpanel/autossl.log &
/scripts/run_autossl --force

The log shows each domain’s validation status, HTTP response codes, and the exact error message from the certificate authority. Look for lines containing ERROR, FAILED, or RATE_LIMITED to pinpoint failures.

Preventive Best Practices for AutoSSL

Once you’ve resolved the immediate error, take these steps to keep AutoSSL running smoothly:

  • Set correct DNS records before adding domains. Never add a domain to cPanel before its A record points to your server. This single practice prevents the majority of AutoSSL failures.
  • Monitor certificate expiry dates. Use WHM → SSL/TLS → View Certificates to see all certificates and their expiration dates. Certificates renewed within 30 days of expiry trigger fewer edge cases.
  • Choose the right CA. Let’s Encrypt certificates expire every 90 days and require more frequent AutoSSL runs. Sectigo certificates last longer (one year) but have different rate limits. For busy servers with many domains, Let’s Encrypt’s shorter lifespan may increase validation traffic.
  • Keep cPanel updated. AutoSSL improvements ship with cPanel updates. Running an outdated version may miss critical bug fixes in the validation process.
  • Automated monitoring. Set up a cron job to email you if AutoSSL fails: 0 6 * * * /scripts/run_autossl --notify-only

Key Takeaways

  • Most AutoSSL errors stem from DNS misconfiguration — verify your A records point to the correct server IP before troubleshooting anything else.
  • Rate limiting is common; wait 24 hours before retrying, and use /scripts/run_autossl --force --verbose to get detailed output.
  • HTTP-01 validation requires port 80 to be accessible — proxies like Cloudflare and HTTPS redirects are the top culprits for validation failures.
  • AutoSSL logs at /var/log/cpanel/autossl.log contain the most specific error messages and should be your first stop for diagnosis.
  • Preventive DNS hygiene (set records before adding domains) and regular cPanel updates eliminate the majority of recurring AutoSSL issues.
  • For domains behind reverse proxies, switch to DNS-01 validation in WHM to bypass IP-based validation failures.