Proudly Canadian 
You log into cPanel or get an alert from your hosting provider: AutoSSL failed to renew your certificate. Or worse, you find out from a visitor that your site is throwing a security warning. Either way, it's one of those problems that feels urgent but is almost always fixable once you know where to look.
The frustrating thing about AutoSSL failures is that the error message rarely tells you what's actually wrong. "Validation failed" or "Could not verify domain ownership" doesn't give you much to go on. What's usually happening underneath is that the certificate authority couldn't reach your server to complete the verification — and that's almost always a DNS or accessibility issue, not a problem with SSL itself.
This guide walks through how AutoSSL validation actually works, why it fails, and how to fix each specific cause — from DNS mismatches and Cloudflare interference to firewall rules and Let's Encrypt rate limits.
Quick Fix Summary
- Confirm your domain's DNS is pointing to the correct server IP
- Check that your site is accessible over plain HTTP (not just HTTPS)
- Temporarily disable Cloudflare proxy if it's active
- Check for conflicting or outdated DNS records
- Run AutoSSL manually from WHM and read the log output
- Check for Let's Encrypt rate limit blocks if it has failed multiple times recently
How AutoSSL Validation Works (and Why It Fails)
Before jumping into fixes, it's worth understanding exactly what happens during an AutoSSL renewal — because once you understand the process, the causes of failure become obvious.
AutoSSL uses a method called HTTP-01 domain validation (when using Let's Encrypt or Sectigo's DV tier). Here's the sequence:
- cPanel's AutoSSL system contacts the certificate authority and requests a new certificate for your domain
- The certificate authority generates a unique token and tells AutoSSL to place it at a specific URL on your server — something like
http://yourdomain.com/.well-known/acme-challenge/[token] - AutoSSL places that token file on your server
- The certificate authority then makes an HTTP request to that URL from its own servers to verify the file is there
- If it can reach the file and the token matches, validation succeeds and the certificate is issued
- If anything prevents the authority from reaching that URL — wrong DNS, firewall, redirect, proxy — the validation fails and no certificate is issued
This means AutoSSL failures are almost never a problem with SSL configuration on your server. They're a problem with domain reachability. The certificate authority simply couldn't get through to verify ownership.
Step 1: Verify Your DNS Is Pointing to the Right Server
This is the most common cause by a significant margin. Your domain's A record needs to point to the IP address of the server where your cPanel account lives. If it's pointing to an old server, a wrong IP, or nothing at all, the certificate authority's validation request will never reach your server.
To check your current DNS resolution, open a terminal and run:
dig yourdomain.com +short
or use an online tool like MXToolbox's DNS lookup. The IP returned should match your server's IP exactly.
To find your server's correct IP:
- Log into cPanel and look for the "Shared IP Address" or "IP Address" in the General Information sidebar on the right side of the home screen
- In WHM, it's listed under Server Configuration or in the account's summary
- In your WHMCS client area, navigate to My Services, click on your hosting package, and the server IP is listed in the product details
If the IP from your DNS lookup doesn't match your server IP, that's your problem. Update the A record in your DNS management panel to the correct IP and wait for propagation before running AutoSSL again.
Step 2: Check That Your Site Is Reachable Over HTTP
AutoSSL's validation uses plain HTTP, not HTTPS. This catches a lot of people off guard. Even if your site works perfectly over HTTPS, if something is blocking or redirecting HTTP requests, AutoSSL will fail.
Open a browser or use curl to test plain HTTP access:
curl -I http://yourdomain.com/.well-known/acme-challenge/test
You might get a 404 response, which is fine — that just means the file doesn't exist yet, but it confirms HTTP access is working. What you don't want to see is a connection timeout, a 403 Forbidden, or a redirect that goes somewhere other than your server.
Common things that block HTTP validation:
- Force HTTPS redirects in .htaccess: If your .htaccess file redirects all HTTP traffic to HTTPS before the validation token can be served, the certificate authority's request gets redirected and the check fails. Some hosting setups do this aggressively. You can add an exception for the .well-known directory (more on this below).
- Firewall rules blocking port 80: If your server's firewall is blocking inbound connections on port 80, the validation request can't get through. Port 80 needs to be open even if you redirect visitors to HTTPS.
- Maintenance mode or password protection: If your site is in maintenance mode or behind HTTP basic authentication, validation requests will receive a non-200 response and fail.
- ModSecurity rules: Some WAF rules can block requests to the .well-known directory as a false positive.
If you have a global HTTP-to-HTTPS redirect in .htaccess, you can add an exception for AutoSSL validation by placing this before your redirect rules:
RewriteEngine On
RewriteCond %{REQUEST_URI} !^/.well-known/acme-challenge/
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
This tells Apache to skip the HTTPS redirect for anything in the .well-known path, which is exactly where AutoSSL places its validation tokens.
Step 3: Disable Cloudflare Proxy During Renewal
If your domain is using Cloudflare's proxy (orange cloud icon), this is one of the most common reasons AutoSSL fails silently. Here's what happens: when the certificate authority tries to access the validation token at http://yourdomain.com/.well-known/acme-challenge/..., the request hits Cloudflare's servers instead of yours. Cloudflare may cache a response, return an error, or behave in a way that doesn't match what the certificate authority expects — causing validation to fail even though your server is perfectly healthy.
The fix is straightforward:
- Log into Cloudflare and go to the DNS tab for your domain
- Find the A record for your root domain (@) and www
- Click the orange cloud icon to switch it to grey (DNS only mode)
- Save the change and wait two to three minutes
- Go to WHM and run AutoSSL manually (see Step 5)
- Once the certificate renews successfully, re-enable the Cloudflare proxy
Alternatively, if you don't want to disable the proxy every time AutoSSL runs, you can use Cloudflare's SSL mode set to "Full" or "Full (Strict)" and install the certificate on your origin server. This way Cloudflare handles visitor-facing SSL independently of AutoSSL, though AutoSSL still handles the origin certificate.
Step 4: Check for Conflicting DNS Records
Even when your main A record is correct, other DNS records can confuse validation. Things to look for:
Conflicting AAAA records
If your domain has an AAAA (IPv6) record pointing to an address that isn't your server, the certificate authority may try to validate over IPv6 and fail. Unless your server is actually configured for IPv6, remove any AAAA records or ensure they point to the correct IPv6 address.
To check for AAAA records:
dig AAAA yourdomain.com +short
If this returns an IP that isn't your server, delete that record from your DNS panel.
CAA records restricting the certificate authority
CAA (Certification Authority Authorization) records specify which certificate authorities are allowed to issue certificates for your domain. If you have a CAA record that doesn't include Let's Encrypt or Sectigo (depending on which AutoSSL provider your host uses), all certificate issuance attempts will be blocked.
Check for CAA records:
dig CAA yourdomain.com +short
If you see a CAA record that only allows, say, DigiCert, and your AutoSSL uses Let's Encrypt, you need to either add an entry permitting Let's Encrypt or remove the CAA restriction entirely. A permissive CAA record for Let's Encrypt looks like:
yourdomain.com. CAA 0 issue "letsencrypt.org"
Old or stale subdomain records
AutoSSL doesn't just renew the certificate for your root domain — it tries to cover all subdomains associated with your cPanel account (www, mail, webmail, cpanel, etc.). If any of these subdomains have outdated A records pointing to a different server, validation for those subdomains will fail and AutoSSL may refuse to issue a certificate at all rather than issue a partial one.
Review all DNS records for your domain and remove or update any subdomains that aren't actively pointing to your current server.
Step 5: Run AutoSSL Manually and Read the Logs
Once you've addressed the likely causes above, it's time to trigger AutoSSL manually and see exactly what happens. The logs are genuinely useful here — they'll tell you precisely which domain or subdomain failed and why.
Running AutoSSL from WHM
- Log into WHM (usually at yourdomain.com:2087 or server.yourdomain.com/whm)
- In the left search bar, type "AutoSSL" and click Manage AutoSSL
- Click the Manage Users tab
- Find the cPanel account you want to renew and click Run AutoSSL
- The process runs in the background — click the Logs tab to watch progress in real time
Running AutoSSL from cPanel (limited)
If you only have cPanel access (not WHM), navigate to SSL/TLS Status under the Security section. This shows the current certificate status for each domain and subdomain. There's a button to run AutoSSL from here too, though the log detail is more limited than from WHM.
Reading the log output
The AutoSSL log is the most useful diagnostic tool available. Key things to look for:
- "The domain resolved to an IP address..." — tells you which IP the validation check found. If it doesn't match your server, your DNS is wrong.
- "HTTP DCV: The system failed..." — HTTP domain control validation failed. Something is blocking port 80 or the .well-known path.
- "Rate limit exceeded" — Let's Encrypt has temporarily blocked further issuance attempts. See Step 6.
- "The certificate authority returned the following error" — followed by a specific error message from Let's Encrypt or Sectigo that usually points directly to the problem.
Step 6: Check for Let's Encrypt Rate Limits
If AutoSSL has been failing and retrying repeatedly, you may have hit Let's Encrypt's rate limits. Let's Encrypt allows a maximum of 5 certificate issuances per registered domain per week. Each failed attempt that got far enough in the process may count against this limit.
You can check if you've hit the rate limit by visiting https://crt.sh/?q=yourdomain.com. This shows all certificates issued for your domain across all authorities. If you see many recent entries from Let's Encrypt within the last seven days, that's a sign you've been hitting the rate limit.
If you're rate limited, you have two options:
- Wait it out. The rate limit window is seven days from the first failed attempt. Once it clears, fix the underlying issue first, then let AutoSSL run.
- Switch AutoSSL providers temporarily. If your WHM has Sectigo (formerly Comodo) AutoSSL available as an alternative provider, you can switch to it while waiting for the Let's Encrypt rate limit to clear. Go to WHM, Manage AutoSSL, and check the Providers tab.
Managing AutoSSL Through WHMCS
If your hosting is managed through our client portal, you can view your SSL certificate status and request manual intervention directly from your client area without needing access to WHM or cPanel.
Navigate to My Services, click on your hosting package, and look for the SSL/Certificate section. If your certificate is showing as expired or failing to renew, open a support ticket directly from that page and include your domain name. Our team can run AutoSSL from the server side, review the logs, and address any configuration issues that require server-level access.
Common Causes at a Glance
Domain not pointing to the correct server
The A record in your DNS points to a different IP than the server where your cPanel account is hosted. This is the single most common cause. Fix: update the A record.
Cloudflare proxy intercepting validation
The orange cloud in Cloudflare is routing the certificate authority's validation request away from your actual server. Fix: temporarily switch to DNS-only mode while AutoSSL renews.
HTTP access blocked or redirected
Port 80 is closed, a firewall rule is blocking access, or an .htaccess redirect is catching the validation request before it can be served. Fix: open port 80 and add a .well-known exception to your redirect rules.
Conflicting AAAA or CAA records
IPv6 records pointing to a non-existent or wrong server, or CAA records restricting which certificate authorities can issue for your domain. Fix: remove incorrect AAAA records and ensure your CAA records permit your AutoSSL provider.
Subdomain DNS mismatch
AutoSSL tries to cover all subdomains on your account. If any subdomain has a stale DNS record, the whole renewal can fail. Fix: audit and clean up subdomain DNS records.
Let's Encrypt rate limit
Too many failed issuance attempts in a short period. Fix: wait out the seven-day window and resolve the underlying issue before trying again.
Server firewall blocking port 80
Even with everything else correct, if the server's firewall (CSF, iptables) is blocking inbound connections on port 80, validation cannot complete. Port 80 must be open even if your site redirects all visitors to HTTPS.
When to Contact Support
Most AutoSSL failures can be resolved by working through the steps above. But some situations genuinely require server-level access to diagnose:
- AutoSSL logs show the correct IP and HTTP access seems fine, but validation still fails
- The error message references a server configuration issue rather than a DNS or accessibility problem
- You're seeing different behavior for different subdomains with no obvious DNS explanation
- ModSecurity or CSF firewall rules are involved and you don't have access to modify them
- Your certificate expired and you need immediate restoration while the underlying issue is resolved
Open a support ticket and include your domain name and a copy of the AutoSSL log output if you have it. The log output alone usually cuts the diagnosis time down significantly.
Gotekky
Need help deciding what to do next?
Tell us what you are seeing and what outcome you need. We will identify whether a managed service, scoped project or paid technical assessment is the right next step.