AutoSSL failures usually come down to three root causes. DNS points somewhere you didn’t expect. Your web stack can’t complete DCV challenges. Or a proxy/WAF modifies requests in a way Let’s Encrypt rejects. This cPanel AutoSSL troubleshooting tutorial gives you a repeatable workflow to pinpoint the exact failure, fix it with minimal blast radius, and verify renewals won’t break again next week.
The steps below assume WHM/cPanel on a VPS or dedicated server. AlmaLinux, Rocky, and CloudLinux are common choices. If you don’t want to babysit updates and service health checks, a managed VPS hosting plan from HostMyCode can handle the routine maintenance that often shows up as “sudden” AutoSSL problems.
What AutoSSL is actually doing (and what it expects)
In cPanel, AutoSSL is the traffic cop for certificates. It verifies domain control (DCV), requests a certificate, installs it on the correct vhost, and updates the certificate store used by services like Exim/Dovecot when applicable.
- DCV method: Usually HTTP-based (a token under
/.well-known/) or DNS-based, depending on provider and configuration. - Critical dependency: The domain’s A/AAAA record must resolve to your server (or to a proxy that forwards the challenge path cleanly).
- Common misconception: “The site loads, so renewal will work.” Not always. A CDN can serve pages fine while blocking or rewriting the DCV request.
Before you change anything: capture the exact AutoSSL error
Start with the log. AutoSSL usually tells you what it tried and what failed.
- In WHM: SSL/TLS → Manage AutoSSL.
- Click Logs (or open the last run details for the affected user).
- Copy the error line(s) for one failing domain. Watch for phrases like DNS DCV, HTTP DCV, timeout, NXDOMAIN, CAA, unauthorized, invalid response, too many redirects, or blocked.
CLI option (handy on busy servers): trigger a run and see verbose output from the shell.
/usr/local/cpanel/bin/autossl_check --user=username --verbose
If you’d rather not expose WHM while you troubleshoot, put admin access behind a safer entry point. HostMyCode customers often use a bastion or tunnel for this. The walkthrough here is solid: SSH port forwarding tutorial.
cPanel AutoSSL troubleshooting tutorial step 1: verify DNS points to the right server
AutoSSL can’t pass DCV if public DNS resolves to the wrong place. You’ll see this during migrations, after IP changes, or when a CDN is only half-enabled.
Check A/AAAA records from outside your server
Run these from your workstation (or any Linux shell using a public resolver):
domain=example.com
# A record
dig +short A $domain
# AAAA record (if you use IPv6)
dig +short AAAA $domain
# Also check www
dig +short A www.$domain
Expected: the answers should match your cPanel server’s public IP. If they don’t, AutoSSL is failing for the right reason.
Confirm the server IP cPanel expects
On the server:
hostname -f
curl -4s ifconfig.me; echo
ip -4 addr show | awk '/inet /{print $2,$NF}'
If you recently moved accounts, keep the cutover tight. Lower TTLs, verify records, then flip.
This checklist is a good companion: DNS cutover tutorial.
Pitfall: split DNS or stale glue records
- If you run custom nameservers (
ns1/ns2), registrar glue can still point to an old IP even when the zone file looks correct. - If you use a DNS cluster, confirm the zone synced and that public resolvers see the same values.
Step 2: test the DCV URL path end-to-end (HTTP and HTTPS)
Most AutoSSL failures happen because the DCV request never reaches the right vhost. The clean test is simple.
Can the public internet fetch a file under /.well-known/ without redirects, auth prompts, or rewrites interfering?
Create a temporary test file for one domain
Document roots vary by account. In WHM you can find them under Account Information → List Accounts. If the docroot is /home/USER/public_html:
USER=username
DOCROOT=/home/$USER/public_html
mkdir -p "$DOCROOT/.well-known/acme-challenge"
echo "autossl-test-$(date +%s)" > "$DOCROOT/.well-known/acme-challenge/ping"
chown -R $USER:$USER "$DOCROOT/.well-known"
chmod -R 755 "$DOCROOT/.well-known"
Fetch it like Let’s Encrypt would
domain=example.com
curl -I http://$domain/.well-known/acme-challenge/ping
curl -I https://$domain/.well-known/acme-challenge/ping
curl -s http://$domain/.well-known/acme-challenge/ping | head
- 200 OK: the path is reachable and behaving normally.
- 301/302 loops: common with forced HTTPS or “www” redirects implemented at the app/CMS layer.
- 403/401: WAF rules, hotlink protection, or deny rules are blocking the request.
- 404: wrong docroot, wrong vhost, or rewrite rules are swallowing the request.
- 522/524/timeout: you’re behind a proxy/CDN or the origin isn’t reachable on port 80/443.
Fix redirect and rewrite issues without weakening your site
You don’t need to rip out your HTTPS redirects. You only need the ACME challenge path to pass through untouched.
If the domain uses .htaccess: add this near the top of the file in the document root:
<IfModule mod_rewrite.c>
RewriteEngine On
# Allow ACME challenges through untouched
RewriteRule ^\.well-known/acme-challenge/ - [L]
</IfModule>
If you’re using Nginx in front: add a location block that allows /.well-known/acme-challenge/ and routes it to the correct root.
The exact config depends on whether Nginx is a reverse proxy or the primary webserver.
If you suspect broader SSL issues (wrong cert presented, missing chain, or SNI surprises), cross-check with: TLS handshake troubleshooting tutorial.
Step 3: confirm ports 80 and 443 are reachable (and not blocked by firewall)
AutoSSL often needs port 80 for HTTP DCV, even if you force HTTPS for normal browsing. Closing port 80 is a common “hardening” move that quietly breaks renewals.
Quick reachability checks
From an external machine:
domain=example.com
# Basic TCP check
nc -vz $domain 80
nc -vz $domain 443
On the server (UFW example):
ufw status verbose
ss -lntp | egrep ':(80|443)\s'
If you’re locked out or traffic is blocked unexpectedly, troubleshoot systematically. Don’t flip rules at random.
This guide is built for that: firewall troubleshooting tutorial.
Common firewall fix patterns
- Allow HTTP and HTTPS on the public interface, and confirm the service is actually listening.
- Don’t expose WHM/cPanel ports (2087/2083) to the world; restrict by IP instead.
- If you use a CDN, allow their IP ranges only where it makes sense. Don’t accidentally block DCV requests.
Step 4: check CAA records (silent blocker for Let’s Encrypt)
CAA records tell certificate authorities whether they’re allowed to issue for your domain. A restrictive CAA (often from a DNS template) can block Let’s Encrypt without obvious “DNS is wrong” symptoms.
Inspect CAA records
domain=example.com
# Show CAA, if present
dig +short CAA $domain
dig +short CAA www.$domain
What to look for: if CAA only allows a different CA, AutoSSL can’t get a Let’s Encrypt certificate. Remove the CAA record, or add an entry that permits Let’s Encrypt.
Example CAA allowing Let’s Encrypt:
example.com. 3600 IN CAA 0 issue "letsencrypt.org"
example.com. 3600 IN CAA 0 issuewild "letsencrypt.org"
After changing DNS, wait for the TTL to expire. Then rerun AutoSSL for the user.
Step 5: catch “wrong vhost” and SNI mix-ups
On servers with many domains, a hostname can resolve to your IP and still hit the wrong virtual host. Apache vhost order and proxy layers are the usual culprits.
Validate which vhost answers for the domain
From the server:
domain=example.com
# Show headers and which cert is served (SNI)
curl -Ik https://$domain/
# Check HTTP Host routing locally
curl -sI -H "Host: $domain" http://127.0.0.1/ | head
If the headers/content clearly belong to another site, correct the vhost mapping in WHM. If Nginx sits in front of Apache, fix the proxy configuration instead.
Step 6: fix AutoSSL failures caused by proxy/CDN mode
If the domain is proxied (common with CDN “orange cloud” modes), DCV may terminate at the CDN edge instead of your origin. Some setups pass the challenge cleanly. Others fail due to caching, redirects, or edge security rules.
How to confirm you’re behind a proxy
domain=example.com
# Check if the A record points to known CDN IP ranges or not your origin
dig +short A $domain
# Check response headers for CDN indicators
curl -I http://$domain/ | egrep -i 'server:|cf-|x-cache|via'
Practical fixes
- Best: use DNS-based DCV if your DNS provider supports automated TXT updates (not always possible in cPanel without provider integration).
- Common: temporarily disable proxying (set DNS to “DNS only”), let AutoSSL issue/install, then re-enable proxying.
- Edge rule approach: configure the CDN to bypass caching and redirects for
/.well-known/acme-challenge/.
Step 7: make AutoSSL renewals reliable across all accounts
After you fix one domain, assume there are more. The same root cause often affects multiple accounts.
Audit for “migration leftovers”
- Old A records pointing at the previous server
- WWW CNAME still pointing to a legacy host
- Stale IPv6 AAAA records you’re not actually serving
- CAA records inherited from a template
Operational checklist (do this monthly)
- In WHM AutoSSL logs, scan for repeated DCV failures.
- Spot-check that port 80 remains open and Apache answers
/.well-known/. - Confirm time is correct (
timedatectl), because TLS validation can fail on skewed clocks. - Keep cPanel updated (patches often include AutoSSL/provider fixes).
If you’re tightening server administration, follow a deliberate order. Start with least-privilege access, then adjust service exposure.
This guide fits well with the workflow above: Sudo setup guide tutorial.
Quick diagnostics table: symptom → likely cause → fix
| AutoSSL symptom | Likely cause | What to do |
|---|---|---|
| DCV: NXDOMAIN | Domain/subdomain missing DNS record | Add A/AAAA (or correct CNAME), wait TTL, rerun AutoSSL |
| DCV: wrong IP | DNS still points to old server or CDN edge | Fix A/AAAA, check registrar glue for nameservers |
| HTTP 301/302 loop on challenge | Rewrite rules force redirect | Exclude /.well-known/acme-challenge/ from rewrites |
| 403 on challenge | WAF, hotlink protection, or deny rules | Allow that path; temporarily disable the blocking rule |
| Timeout / can’t connect | Firewall blocks 80 or service not listening | Open 80, confirm Apache/Nginx is bound and reachable |
| CAA forbids issuance | CAA only allows another CA | Add Let’s Encrypt CAA or remove restrictive CAA |
Summary: the repeatable fix order that saves time
If you follow one rule, follow the order of operations. Check DNS first. Then validate the DCV URL fetch. Next confirm ports and firewall behavior. Only after that should you dig into CAA and proxy/CDN layers.
This sequence keeps you from “fixing” something unrelated while the real blocker stays in place.
If you host client sites on a production server, AutoSSL problems often show up during migrations, IP changes, and security tightening. HostMyCode can help you avoid the rough edges with a HostMyCode VPS sized for cPanel workloads. Or you can offload upkeep to managed VPS hosting while keeping full WHM control.
If AutoSSL failures keep popping up across multiple accounts, the fix usually isn’t “rerun AutoSSL.” It’s a cleaner baseline: DNS you can trust, firewall rules you can explain, and consistent vhost routing. HostMyCode’s VPS plans work well for WHM/cPanel, and managed VPS hosting can handle the day-to-day checks that keep renewals boring.
FAQ
Do I need port 80 open for cPanel AutoSSL?
In many setups, yes. HTTP DCV commonly uses port 80. You can still force HTTPS for normal traffic, but keep port 80 reachable and ensure the ACME challenge path works.
Why does AutoSSL fail even though the website loads?
The site may be loading from a proxy/CDN, or redirects and WAF rules may block /.well-known/acme-challenge/. AutoSSL needs the challenge request to succeed exactly.
How long after DNS changes should I rerun AutoSSL?
Wait at least the DNS record TTL. If you changed nameserver glue at the registrar, propagation can take longer. Confirm with dig against public resolvers before rerunning.
Can CAA records break AutoSSL?
Yes. If CAA restricts issuance to a different CA, Let’s Encrypt won’t issue. Add issue "letsencrypt.org" (and optionally issuewild) or remove the restrictive record.
What’s the safest way to fix redirect loops for DCV?
Don’t remove your HTTPS redirect globally. Instead, add an exception rule so requests to /.well-known/acme-challenge/ bypass redirects and rewrites.