How to Fix AutoSSL Errors in cPanel: A Step-by-Step Guide

by

Nothing kills a morning faster than logging into cPanel to find an AutoSSL error staring at you from the dashboard. The little red badge next to SSL/TLS means that one of your domains just failed to get a free Let’s Encrypt certificate — and if you don’t fix it quickly, your visitors will see the dreaded “Not Secure” warning in their browser.

AutoSSL in cPanel is supposed to be a set-it-and-forget-it feature. And most of the time, it is. But when it breaks — whether from DNS misconfigurations, server rate limits, or certificate validation failures — it can be frustrating to diagnose, especially if you’re not sure where to start. This guide walks you through the most common AutoSSL errors, how to read the logs, and the exact steps to resolve each one.

What AutoSSL Does (and Why It Sometimes Fails)

AutoSSL is a cPanel feature that automatically provisions, installs, and renews SSL certificates for your domains. By default, cPanel uses Let’s Encrypt as the certificate authority (CA), though some hosting providers configure it to use cPanel’s built-in certificate service, Sectigo, or another provider.

Here’s what AutoSSL checks before issuing a certificate:

  • The domain’s DNS records must point to the correct IP address
  • The domain must resolve publicly (not just locally)
  • The web server must respond properly for both the domain and any subdomain verification challenges
  • The domain must not have an existing valid certificate that’s still within its renewal window
  • You haven’t exceeded Let’s Encrypt’s rate limit (50 certificates per domain per week)

If any of these conditions isn’t met, AutoSSL logs a failure and retries periodically. The key to fixing it is understanding which condition failed.

Step 1: Check the AutoSSL Logs

Before making changes, pull the log to see exactly what went wrong. cPanel logs every AutoSSL run, and the error messages are usually descriptive enough to point you in the right direction.

From the cPanel Interface

  1. Log in to cPanel
  2. Navigate to SSL/TLS Status (under the Security section)
  3. Click the View Details button next to any domain with a failed AutoSSL status
  4. Read the error message displayed — this is often enough to diagnose the issue

From WHM (Server-Level)

If you have WHM access, you can check the full AutoSSL log for all accounts:

# View the AutoSSL log for a specific user
cat /var/cpanel/logs/autossl/username.log

# Check the global AutoSSL log
cat /var/log/autossl.log

# Tail the log in real time during a manual run
tail -f /var/log/autossl.log

You can also trigger a manual AutoSSL check in WHM by going to Home → SSL/TLS → Manage AutoSSL and clicking Run AutoSSL for the affected user.

Step 2: Fixing the Most Common AutoSSL Errors

Here are the errors you’re most likely to encounter and how to resolve each one.

Error: “Domain is not pointing to the server IP”

This is the most common AutoSSL failure. It means the domain’s A record (or CNAME) isn’t resolving to the IP address of your server.

  1. Check your domain’s DNS at your DNS provider (GoDaddy, Cloudflare, Namecheap, etc.)
  2. Verify the A record points to your server’s IP address. You can find your server’s IP in cPanel under General Information or Statistics
  3. Use a DNS lookup tool: dig example.com +short or nslookup example.com
  4. If using Cloudflare, ensure DNS is set to DNS Only (grey cloud) — AutoSSL does not work with Cloudflare’s proxied (orange cloud) DNS for the HTTP-01 challenge. If you must use proxied DNS, switch your SSL validation to DNS-01 via a plugin or third-party service
  5. Wait for DNS propagation (up to 48 hours if you just changed records)

Once DNS resolves correctly, run AutoSSL manually from the SSL/TLS Status page. It should succeed within minutes.

Error: “No valid IP found for domain” or “Could not connect to domain”

This error means cPanel cannot reach the domain at all. The domain might not resolve, the server may be blocking the connection, or the domain could be misconfigured in the web server.

  1. Verify the domain resolves from outside your server: ping example.com from another machine
  2. Check that the domain exists in Apache/Nginx: httpd -S (as root) should show the domain in the vhost list
  3. Ensure the domain’s document root exists and contains at least an index.html file
  4. Check that port 80 (HTTP) is open and the server responds: curl -I http://example.com
  5. If using a firewall, confirm port 80 is not blocked on the server side

Error: “Rate limit exceeded”

Let’s Encrypt imposes rate limits to ensure fair usage. The relevant limits are:

  • 50 certificates per registered domain per week
  • 300 pending authorizations per account per week
  • 5 failed validation attempts per domain per hour

You’re most likely to hit these limits during active development or debugging, especially if you’re repeatedly triggering AutoSSL attempts. The fix is simply to wait — the limit resets on a rolling basis. You can check your current rate limit status at Let’s Encrypt’s rate limit page.

To avoid rate limits in the future, reduce the number of subdomains per certificate or use a wildcard certificate for multiple subdomains under one domain.

Error: “Challenge failed: The CA was unable to validate the domain”

The HTTP-01 challenge requires Let’s Encrypt to reach http://yourdomain.com/.well-known/acme-challenge/ with a specific token. If this fails, Let’s Encrypt cannot confirm you control the domain.

  1. Check that the .well-known directory exists and is readable by the web server
  2. Verify there’s no .htaccess rule blocking access to the .well-known folder. A common culprit is a rewrite rule that redirects everything to HTTPS — since the challenge comes over HTTP, the redirect breaks validation
  3. Add this rule to .htaccess to ensure the challenge path isn’t blocked: 
    RewriteEngine On
RewriteRule ^\.well-known/acme-challenge - [L]
  4. For WordPress sites, install the Really Simple SSL plugin, which includes built-in fixes for ACME challenge routing

Error: “SSL certificate already exists for this domain”

This isn’t really an error — it means the domain already has a valid certificate. But if you’re seeing this while knowing the certificate is expired or about to expire, the issue may be that cPanel thinks a valid certificate exists when it doesn’t.

  1. Go to SSL/TLS → Manage SSL Sites in cPanel
  2. Check the certificate expiration dates for the affected domain
  3. If the certificate is expired, delete the certificate entry from the list
  4. Run AutoSSL again to force a fresh certificate request

Step 3: Verify the Certificate Was Installed Correctly

After AutoSSL runs successfully, don’t assume everything works. Verify the certificate was installed and is being served properly.

  1. Check from your browser: Visit https://yourdomain.com and click the padlock icon. It should show “Connection is secure” with a valid certificate
  2. Use an SSL checker: Go to SSL Labs and enter your domain for a full certificate chain analysis
  3. Check from the command line: echo | openssl s_client -connect yourdomain.com:443 -servername yourdomain.com 2>/dev/null | openssl x509 -noout -dates — this shows the certificate validity period
  4. Verify AutoSSL status in cPanel: Return to SSL/TLS Status and confirm the domain shows “AutoSSL Certificate” with a green checkmark and an expiration date in the future

Step 4: Prevent AutoSSL Issues Going Forward

Once your certificates are working, a few proactive steps will keep AutoSSL running smoothly.

  • Monitor certificate expiry: Set up a monthly calendar reminder to check SSL/TLS Status. AutoSSL auto-renews at 30 days before expiry, but if it fails silently you’ll only notice when the browser warning appears
  • Keep DNS records current: Whenever you add, remove, or change a domain’s DNS, verify DNS resolution before expecting AutoSSL to work
  • Don’t mix manual certificates with AutoSSL: If you install a custom (paid) SSL certificate from a third-party CA, cPanel AutoSSL will stop managing that domain. This is by design, but it can be confusing when AutoSSL reports the domain as skipped on subsequent runs
  • Use WHM’s Manage AutoSSL interface: Server administrators should configure AutoSSL in WHM under Home → SSL/TLS → Manage AutoSSL. Here you can set the default certificate authority, exclude specific domains, and configure notification email addresses for failures
  • Enable email notifications: In WHM’s AutoSSL configuration, check the option to send an email when AutoSSL encounters errors. This gives you a proactive notification instead of discovering the issue when a visitor reports a broken site

Key Takeaways

  • AutoSSL relies on DNS resolution and HTTP connectivity — most failures trace back to a domain not pointing to the correct server IP
  • Always check the AutoSSL logs first. The error message is specific enough to tell you exactly what’s wrong
  • Cloudflare’s proxied DNS (orange cloud) blocks HTTP-01 challenges. Use DNS-only mode or switch to a DNS-01 validation method
  • Let’s Encrypt rate limits are self-healing. If you hit one, wait it out and avoid repeated auto-renewal retries that waste your quota
  • After fixing an AutoSSL issue, always verify the certificate installed correctly using an SSL checker or command-line tools
  • Proactive monitoring — DNS hygiene, expiry checks, and WHM notification emails — prevents most AutoSSL emergencies before they happen