How to Fix AutoSSL Errors in cPanel: Troubleshooting Common SSL Certificate Issues

by

AutoSSL is one of the most valuable features in modern cPanel deployments. It automatically provisions, installs, and renews free SSL certificates — typically through Let’s Encrypt or cPanel’s built-in Certificate Authority — so your domains stay secured with HTTPS without manual intervention. When it works, you barely notice it. When it breaks, your visitors see browser security warnings, email delivery can fail, and site trust takes an immediate hit.

AutoSSL errors are frustrating because the feature is supposed to be automatic. But in practice, domain validation failures, DNS misconfigurations, rate limits, and server-level issues can all stop AutoSSL in its tracks. This guide walks through the most common AutoSSL errors in cPanel and shows you exactly how to resolve each one.

Understanding How cPanel AutoSSL Works

Before troubleshooting, it helps to understand the AutoSSL lifecycle. cPanel’s AutoSSL system runs on a scheduled basis — typically once per day — and checks every domain on the server to determine whether a valid certificate exists. If a domain is missing a certificate or its existing certificate is about to expire, AutoSSL attempts to issue a new one automatically.

The process uses the Automated Certificate Management Environment (ACME) protocol, most commonly with Let’s Encrypt as the Certificate Authority (CA). The CA must verify that you control the domain before issuing the certificate. This verification happens through one of several challenge types:

  • HTTP-01: The CA places a token file on your server at http://yourdomain.com/.well-known/acme-challenge/ and checks that it’s accessible
  • DNS-01: The CA looks for a specific DNS TXT record on your domain to prove ownership
  • TLS-ALPN-01: The CA attempts a TLS connection on port 443 to verify control

cPanel typically uses the HTTP-01 challenge, which means the challenge file must be reachable on port 80 through your domain. Any obstacle in that chain — DNS, web server configuration, firewall rules, or file permissions — will cause the verification to fail.

Common AutoSSL Errors and Their Fixes

1. Certificate Validation Failed (HTTP-01 Challenge Failure)

This is the most common AutoSSL error. You’ll see it logged in WHM under Home » SSL/TLS » Manage AutoSSL with a message like “The CA was unable to verify the domain.” The root cause is almost always that the HTTP-01 challenge file could not be fetched.

To diagnose and fix this:

  1. Test direct domain access: Run curl -I http://yourdomain.com/.well-known/acme-challenge/test from an external server. If you get a 404 or connection timeout, validation will fail.
  2. Check DNS resolution: Ensure your domain’s A record points to the correct server IP. Use dig yourdomain.com +short to verify.
  3. Check for redirect loops: If your site forces HTTPS with a 301 redirect, the HTTP challenge URL must still be accessible. Ensure your .htaccess or web server config doesn’t redirect the /.well-known/ path.
  4. Verify the directory exists: cPanel creates /.well-known/acme-challenge/ automatically, but a custom file permission setup or security hardening rule may block it. The directory should be owned by the cPanel user and readable by the web server.

2. Rate Limits Hit by Let’s Encrypt

Let’s Encrypt imposes rate limits to prevent abuse. The most restrictive limits are 50 certificates per registered domain per week and 300 failed validation attempts per account per hour. If you have many domains, subdomains, or if AutoSSL has been repeatedly failing, you may hit these limits.

Signs of rate limiting include AutoSSL logs showing “too many certificates already issued” or “rate limit exceeded.” To handle this:

  • Check your current rate limit status at Let’s Encrypt’s status page or by monitoring the Retry-After header in failure responses
  • Wait it out: Most rate limits reset within an hour (failed attempts) or a week (certificate counts)
  • Reduce certificate count: Use a single wildcard certificate (*.yourdomain.com) instead of individual certificates for each subdomain
  • Switch to staging CA for testing: Configure AutoSSL to use Let’s Encrypt’s staging environment (with much higher rate limits) while you debug, then switch back to production

3. Domain Not Served by This Server

AutoSSL will refuse to issue a certificate for a domain that isn’t properly configured on the server. You’ll see this error when adding a new addon domain or parked domain that hasn’t been fully provisioned, or when DNS for the domain still points elsewhere after migration.

Fix this by verifying that:

  • The domain is listed under Domains in cPanel and the document root exists
  • DNS records point to your server’s IP address and have propagated (use whatsmydns.net to check globally)
  • The domain’s virtual host entry exists in Apache/Nginx — check /etc/apache2/conf.d/userdata/ or the equivalent on your system
  • You’ve waited at least 15-30 minutes after adding the domain before running AutoSSL

4. AutoSSL Certificate Not Renewing

Let’s Encrypt certificates are valid for 90 days. cPanel’s AutoSSL should automatically renew certificates starting 30 days before expiration, but sometimes renewal doesn’t trigger properly.

If a certificate is about to expire and AutoSSL hasn’t renewed it:

  1. Go to SSL/TLS » Manage AutoSSL in WHM for the affected domain
  2. Click Run AutoSSL to force an immediate check
  3. Check that the cPanel AutoSSL cron job (/usr/local/cpanel/bin/autossl) is enabled — verify it appears in the server’s cron configuration
  4. Look in /usr/local/cpanel/logs/error_log for AutoSSL-specific errors
  5. If the issue persists, try revoking the existing certificate and letting AutoSSL issue a fresh one

5. Web Server Not Responding on Port 80

The HTTP-01 challenge requires port 80 to be open and serving requests for the domain. If you’ve recently moved to a fully HTTPS-only setup and blocked port 80 entirely, AutoSSL will fail.

To resolve this while maintaining a security-first posture:

  • Keep port 80 open but set up a 301 redirect to HTTPS for all traffic except the /.well-known/ path
  • Add this rule in your .htaccess before the general HTTPS redirect:
    RewriteCond %{REQUEST_URI} !^/\.well-known/
  • Verify the firewall is not blocking port 80 — check with iptables -L -n | grep :80 or your firewall manager in WHM
  • If using Cloudflare or another reverse proxy, ensure Proxied (orange cloud) mode is enabled so the challenge request reaches your origin server

How to Run AutoSSL Manually for Testing

After applying any fix, you shouldn’t have to wait up to 24 hours for the next scheduled check. You can trigger AutoSSL immediately:

  1. Log into WHM as root
  2. Navigate to Home » SSL/TLS » Manage AutoSSL
  3. Select the user or domain you’re troubleshooting
  4. Click Run AutoSSL and watch the live log output

From the command line as root, you can also run:
/usr/local/cpanel/bin/autossl --user=username --verbose

The verbose flag shows real-time output including which CA is being contacted, what challenge type is used, and exactly where the validation fails if it does.

Key Takeaways

  • HTTP-01 challenge failures are the most common AutoSSL issue — verify DNS, port 80 accessibility, and that /.well-known/ isn’t being redirected
  • Let’s Encrypt rate limits can block AutoSSL for up to a week; use staging environments for testing and wildcard certificates to reduce the number of certificates needed
  • Newly added domains need 15-30 minutes for DNS propagation and full server provisioning before AutoSSL can issue certificates
  • Always keep port 80 open for AutoSSL verification even if you redirect all other traffic to HTTPS
  • Force-run AutoSSL from WHM or the command line to test fixes immediately instead of waiting for the daily cron job
  • Monitor /usr/local/cpanel/logs/error_log and the Manage AutoSSL interface in WHM for detailed error messages