Part of the guide: Website Security on Shared Hosting: Practical Guides

cPanel AutoSSL Not Renewing? Fix DCV Errors (2026)

By Faizan Published October 24, 2026 17 min read Security

Your website works over HTTPS, but cPanel suddenly shows "Renew soon. Your domain is at risk!" You click Run AutoSSL, and the certificate still doesn't renew because domain control validation (DCV) failed.

If cPanel AutoSSL is not renewing, read the AutoSSL log before changing anything. Most failures come from one of these:

Wrong DNS records
Blocked .well-known validation files
HTTPS redirects
Cloudflare settings
A subdomain that no longer points to your hosting server

Fix the check that's failing, rerun AutoSSL and verify the installed certificate's expiry date.

Renewal matters more every year. The CA/Browser Forum cut the maximum certificate lifetime to 200 days on March 15, 2026, with further cuts scheduled. Let's Encrypt is shortening its default from 90 days to 64 days in February 2027, and to 45 days in February 2028.

For a cPanel user, the SSL installation process doesn't change. The difference is that broken renewal automation leaves you less time to notice and recover.

How cPanel AutoSSL renewal actually works

AutoSSL requests and installs free domain-validated certificates for the domains on a cPanel account. Before issuing a certificate, the certificate authority must confirm that you control each domain. That check is Domain Control Validation (DCV).

For HTTP-based validation, a temporary file is published at a predictable URL:

Let's Encrypt (current default):
public_html/.well-known/acme-challenge/

Legacy cPanel/Sectigo:
public_html/.well-known/pki-validation/

cPanel's own pre-check:
public_html/.well-known/cpanel-dcv/

public_html here means the document root of the domain being validated. For an addon domain or a Laravel app, that's a different folder.

The certificate authority requests the file and checks its content. Validation fails if any of these happen:

The request reaches a different server.
The request hits a redirect that loses the file.
A rewrite rule returns 404.
Security rules block the request.

A 404 for a test URL you made up is normal. A 404 for the real token at the moment the certificate authority requests it is the failure.

If the account's DNS is managed on the cPanel server itself, AutoSSL can also validate through DNS by adding a TXT record. A domain is validated if either method succeeds. With external DNS such as Cloudflare nameservers, DNS DCV can't work because cPanel can't edit those records. HTTP DCV is then the only route.

When does AutoSSL attempt renewal?

According to cPanel's renewal documentation:

Certificate type	Renewal window
Let's Encrypt via AutoSSL	Within 29 days of expiry
cPanel-provided certificates (legacy Sectigo)	Within 15 days of expiry
Non-AutoSSL certificates	Last 3 days before expiry, only if WHM allows AutoSSL to replace them

Let's Encrypt is now cPanel's default AutoSSL provider. cPanel deprecated its Sectigo provider in version 118, removed it in version 120, and stopped supporting it on every version after the end of 2024. The 15-day rule only matters if a legacy Sectigo certificate is still installed.

Because of certificate authority rate limits, AutoSSL gives new certificates priority over renewals. That's one reason repeatedly clicking Run AutoSSL doesn't necessarily issue a new certificate.

cPanel AutoSSL not renewing: read the actual DCV error

Start in cPanel:

cPanel
  > Security
  > SSL/TLS Status
  > Run AutoSSL

On some servers, SSL/TLS Status appears as a Status tab inside SSL/TLS Certificates instead of a separate page. Your host chooses which layout you get, and whether Run AutoSSL is shown at all.

Run AutoSSL once and read the result for each domain. If your account doesn't show detailed messages, ask your host for the AutoSSL log for your domain.

If you have Terminal or SSH access, you can do the same from the command line:

# Start an AutoSSL check for your own account
uapi SSL start_autossl_check

# A few minutes later, list the problems AutoSSL recorded
uapi --output=jsonpretty SSL get_autossl_problems

WHM administrators have more detail:

WHM > SSL/TLS > Manage AutoSSL > Logs

Root users on a VPS can also run /usr/local/cpanel/bin/autossl_check --user=username. The raw logs are kept in /var/cpanel/logs/autossl for 30 days.

Don't troubleshoot every possible SSL problem. Match the error to its likely cause:

AutoSSL message	What it usually means
`TOTAL_DCV_FAILURE`	Every domain in that attempt failed validation
`resolved to an IP address that does not exist on this server`	DNS points somewhere unexpected
`forbids DCV HTTP redirections`	A redirect is interfering with validation
`404 (Not Found)` on the DCV file	The token isn't being served from where it was written
`SECURED_DOMAIN_DCV_FAILURE`	A hostname on the current certificate failed validation

For example:

ERROR Impediment: TOTAL_DCV_FAILURE:
Every domain failed DCV.

Both HTTP and DNS validation failed for every eligible domain in that run. It doesn't mean the certificate has expired. The existing certificate stays valid until its notAfter date, even while renewal keeps failing.

To check validation from outside your server, run the domain through Let's Debug. It tests DNS, IPv6, redirects and HTTP access the way Let's Encrypt sees them.

What "Renew soon. Your domain is at risk!" really means

This warning confused many cPanel users in 2026. According to cPanel's own KB article, it appears when an AutoSSL certificate is about 30 days from expiration. It shows for every AutoSSL-managed certificate, whether or not validation is actually failing. cPanel tracks the issue as CPANEL-51680, and the article says there's no way to hide the warning.

The warning on its own doesn't prove anything. What to do:

Check the domain's status in SSL/TLS Status and the AutoSSL log.
If the log shows no errors: AutoSSL will renew inside its 29-day window, and the warning disappears after renewal.
If the log shows DCV errors: use the fixes below.

Check the certificate visitors actually receive:

echo | openssl s_client \
  -connect example.com:443 \
  -servername example.com 2>/dev/null \
  | openssl x509 -noout -issuer -dates

notAfter is the expiry date.

For a Cloudflare-proxied site, this shows Cloudflare's edge certificate, not your cPanel certificate. To see the origin certificate, connect to your server's IP directly while sending the real hostname:

echo | openssl s_client \
  -connect 203.0.113.10:443 \
  -servername example.com 2>/dev/null \
  | openssl x509 -noout -issuer -dates

Replace 203.0.113.10 with the IP shown under General Information in cPanel.

Fix the four most common DCV failures

Fix 1: Check A, AAAA and nameserver records

DNS is the first place I'd look when AutoSSL reports the wrong server IP. Suppose your domain is example.com.

On Linux or macOS:

dig +short A example.com
dig +short AAAA example.com
dig +short A www.example.com
dig +short AAAA www.example.com
dig +short NS example.com

On Windows, nslookup does the same job:

nslookup -type=A example.com
nslookup -type=AAAA example.com
nslookup -type=NS example.com

Compare the addresses with the server IP under General Information in cPanel.

If the site should be on 203.0.113.10 but the domain resolves to a previous host, AutoSSL is validating the wrong machine. (203.0.113.10 is a documentation example. Use your real IP.)

Edit DNS where your domain's authoritative nameservers are, as shown by the NS lookup. Changing records in cPanel's Zone Editor does nothing if the nameservers belong to Cloudflare or your registrar.

Don't overlook IPv6

An outdated AAAA record is one of the most frustrating causes, because the website looks fine to you over IPv4.

Let's Encrypt always tries IPv6 first when a domain has an AAAA record. It retries over IPv4 only when the IPv6 connection times out, and only on the first request.

So if the AAAA record points to a server that answers with a 404, or to a redirect, validation fails with no IPv4 fallback.

Test both protocols separately:

curl -4 -I http://example.com/.well-known/acme-challenge/test
curl -6 -I http://example.com/.well-known/acme-challenge/test

If the two responses differ (different status, different Server header, or -6 times out): fix or remove the AAAA record.
If your host doesn't support IPv6 on your account: delete the AAAA record.
If your host gave you a working IPv6 address: correct the record to that address. Don't delete a working IPv6 record just because a renewal failed.

If Cloudflare proxying is on, dig returns Cloudflare's addresses instead of your origin. Check the origin target inside the Cloudflare DNS dashboard instead.

Fix 2: Stop .htaccess redirects from blocking DCV

This problem is common after adding HTTPS enforcement or changing a Laravel deployment. A typical HTTPS redirect looks like this:

RewriteEngine On

RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

Let's Encrypt itself follows redirects to HTTP or HTTPS on the standard ports. A redirect breaks validation in three situations:

cPanel's own pre-check, and the legacy Sectigo provider, don't accept redirects at all. That's the forbids DCV HTTP redirections message.
The redirect sends the request to another place: a different domain, a different server, or a different folder where the token file doesn't exist.
A front-controller rule sends the token request to index.php, which returns the app's 404 page.

The Laravel version of the last problem is easy to create by accident. If the document root is the project folder (not public/) and .htaccess rewrites everything into public/, then:

cPanel writes the token to project/.well-known/acme-challenge/.
Your rewrite turns the request into project/public/.well-known/acme-challenge/.
The file isn't there, so validation gets a 404.

Redirects created through cPanel's Redirects interface usually include DCV exclusions automatically. Hand-written redirects and framework .htaccess files don't.

Add the validation exclusion before redirects

Edit the .htaccess in the document root of the failing domain:

Laravel with public/ as the document root: public/.htaccess
Standard shared hosting: the domain's document root, usually public_html/.htaccess

Add this block above your existing redirect and front-controller rules. Don't replace the file:

<IfModule mod_rewrite.c>
    RewriteEngine On

    # Let certificate authorities and cPanel reach DCV files untouched
    RewriteCond %{REQUEST_URI} ^/\.well-known/acme-challenge/.+$ [OR]
    RewriteCond %{REQUEST_URI} ^/\.well-known/cpanel-dcv/[0-9a-zA-Z_-]+$ [OR]
    RewriteCond %{REQUEST_URI} ^/\.well-known/pki-validation/[A-F0-9]{32}\.txt(?:\ Sectigo\ DCV)?$
    RewriteRule ^ - [END]
</IfModule>

# Your existing HTTPS redirect and Laravel/WordPress rules stay below.

These conditions follow the exclusions in cPanel's guide to preventing AutoSSL from following redirects. That guide applies them in Apache includes; the logic is the same in .htaccess.

[END] (Apache 2.4+) stops all further rewriting for matching requests, so no rule below can redirect or reroute them.

If you're rebuilding the whole file, the .htaccess generator produces HTTPS and www redirects you can paste this block above.

Verify the validation path

Quick check first:

curl -I http://example.com/.well-known/acme-challenge/test

You want a 404 from your own server, with no 301 or 302 in front of it. That's a useful first sign, but it doesn't prove a real token will be served.

For a stronger test, create a temporary file:

public_html/.well-known/acme-challenge/dcv-test-check.txt

Put exactly this text inside:

dcv-test-ok

Then request it:

curl -i http://example.com/.well-known/acme-challenge/dcv-test-check.txt

Expected result (your HTTP version may differ):

HTTP/1.1 200 OK

dcv-test-ok

How to read it:

200 and dcv-test-ok: the path works. Rerun AutoSSL.
301 or 302: a redirect is still running before your exclusion. Move the block higher, or look for a redirect in the parent folder's .htaccess or in cPanel's Redirects.
404: the file isn't where the web server looks. Check the domain's document root in cPanel Domains, and confirm the file sits in that folder.
403: a security rule is blocking dot-folders. Allow /.well-known/.

Delete the test file afterwards. Never edit a token file that AutoSSL created itself.

If the test passes but real validation still fails, check file permissions, CDN rules and any server-level rewrite rules your host controls.

For more deployment-related problems, see the Laravel on cPanel deployment checklist.

Fix 3: Cloudflare redirects and SSL mode

Cloudflare adds another layer between the certificate authority and your hosting server:

Certificate authority / cPanel pre-check
        |
        v
http://example.com/.well-known/acme-challenge/TOKEN
        |
        v
Cloudflare
        |
        v
301 redirect to HTTPS ("Always Use HTTPS")
        |
        v
Origin never receives the original HTTP request

When Cloudflare's Always Use HTTPS redirects HTTP traffic before it reaches your server, checks that refuse redirects (like cPanel's pre-check) fail.

Test whether your origin serves the file when Cloudflare is out of the way. --resolve sends the request straight to your server IP while keeping the real hostname:

curl -i \
  --resolve example.com:80:203.0.113.10 \
  http://example.com/.well-known/acme-challenge/dcv-test-check.txt

Origin returns 200 and the content, but the normal request gets a 301 from Cloudflare: Cloudflare's redirect is the problem.
Origin also fails: the problem is on your server. Go back to Fix 1 and Fix 2.

To test the Cloudflare side, open:

Cloudflare
  > Your domain
  > SSL/TLS
  > Edge Certificates
  > Always Use HTTPS

Turn Always Use HTTPS off temporarily.
Rerun AutoSSL.
Once it succeeds, move HTTPS enforcement to Apache, with the .well-known exclusion from Fix 2 above the redirect.
If your Cloudflare plan's rules let you skip the redirect for /.well-known/* only, that's the cleaner long-term option.

Don't leave the site without any HTTPS redirect after testing.

Redirect loops: an Apache %{HTTPS} off redirect loops only when Cloudflare is in Flexible mode, because Cloudflare connects to your origin over plain HTTP. The fix is to install a valid origin certificate and switch to Full (strict), not to trust forwarded headers in .htaccess.

Full versus Full (strict)

These two Cloudflare SSL modes behave differently:

Full: Cloudflare encrypts traffic to the origin but accepts any certificate there, including self-signed or expired ones.
Full (strict): Cloudflare requires a valid, unexpired origin certificate that covers the hostname.

If the origin certificate expires under Full (strict), visitors see:

Error 526
Invalid SSL Certificate

Temporarily switching to Full can bring the site back, but it removes origin authentication. Treat it as an emergency measure, not a renewal strategy. The real fix is a valid origin certificate and Full (strict).

A Cloudflare edge certificate doesn't replace the certificate on your hosting server.

For hostnames that are always proxied through Cloudflare, another option is a free Cloudflare Origin CA certificate, installed in cPanel under SSL/TLS > Manage SSL sites. Full (strict) trusts it, and it doesn't depend on AutoSSL validation at all.

The catch: browsers don't trust Origin CA certificates. If you ever switch that record to DNS-only (grey cloud), visitors get certificate errors straight away.

Fix 4: One unused subdomain can delay renewal

This is one of the easiest problems to miss. Imagine the current certificate covers:

example.com
www.example.com
mail.example.com
old.example.com

The main website works, but old.example.com no longer points to your cPanel server. AutoSSL may report:

ERROR Impediment: SECURED_DOMAIN_DCV_FAILURE:
One or more currently-secured domains failed DCV.

cPanel tries not to replace a certificate with one that covers fewer names, so one dead subdomain can hold up renewal for the whole certificate. It will eventually issue a reduced certificate as expiry gets very close, but by then you have almost no margin. Don't wait for that.

Open the domain list in SSL/TLS Status and note every hostname that failed. For each one:

Still in use: fix its DNS and hosting configuration (Fix 1 and Fix 2).
Permanently abandoned: remove it from your hosting setup (delete the subdomain or addon domain), or exclude it from AutoSSL.

To exclude a hostname:

Security > SSL/TLS Status
Select the domain
Exclude from AutoSSL

If you use the unified SSL/TLS Certificates screen, the same controls are on its Status tab. Some hosts must enable them first; if they're missing, ask support.

Don't exclude an active mail or application subdomain just to clear the error. Mail clients and apps on that hostname would be left without a valid certificate.

Also, don't delete the currently valid certificate as a troubleshooting step. Remove an old self-signed certificate only when it's really conflicting, and first confirm which certificate is serving production traffic.

Verify the renewal worked

After AutoSSL reports success, check the certificate visitors now receive:

echo | openssl s_client \
  -connect example.com:443 \
  -servername example.com 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

Confirm:

notAfter has moved forward.
The issuer is the one you expect (Let's Encrypt for current AutoSSL).
The Subject Alternative Name list includes every hostname you need, including www.

-ext needs OpenSSL 1.1.1 or newer. On older systems, drop it and use -text.

Then open the site and check the browser console for mixed-content warnings. A renewed certificate won't fix pages that still load scripts, images or stylesheets over http://.

Finally, set up expiry monitoring outside cPanel. This script exits with an alert when the certificate has less than 20 days left. With Let's Encrypt's 29-day renewal window, that means AutoSSL has been failing for over a week:

#!/usr/bin/env bash
domain="example.com"

if ! echo | openssl s_client -connect "$domain:443" -servername "$domain" 2>/dev/null \
  | openssl x509 -noout -checkend $((20 * 86400)); then
  echo "WARNING: $domain certificate expires within 20 days - check AutoSSL"
  exit 1
fi

Schedule it daily; the cron job generator builds the line for you. cPanel emails cron output by default, so the warning reaches your inbox. Under Cloudflare proxy, point -connect at your origin IP as shown earlier, or the script only watches Cloudflare's edge certificate.

If you need hands-on help with a failed renewal, contact HeadsNTail with the exact AutoSSL error message.

What changes in 2026–2028: shorter SSL certificates

The CA/Browser Forum's SC-081v3 schedule sets the maximum lifetime of newly issued public certificates:

Effective date	Maximum validity
March 15, 2026	200 days
March 15, 2027	100 days
March 15, 2029	47 days

Let's Encrypt has its own schedule:

Date	Let's Encrypt validity
Default in October 2026	90 days
May 13, 2026	Optional 45-day `tlsserver` profile
February 10, 2027	64-day default
February 16, 2028	45-day default

These are certificate lifetimes, not renewal intervals. Let's Encrypt recommends ACME Renewal Information (ARI) where the client supports it. Otherwise, renew at about two-thirds of the certificate's lifetime; a hardcoded 60-day renewal won't work with 45-day certificates. Source: Let's Encrypt's certificate lifetime announcement.

AutoSSL handles the scheduling for you. What shrinks is the slack: with a 45-day certificate, a failure that goes unnoticed for three weeks becomes an outage.

Why I check this after every .htaccess change

I run HeadsNTail on a Namecheap shared cPanel account, so its SSL renewal depends on the hosting environment.

In October 2026, I rebuilt the site's .htaccess with forced HTTPS, a www redirect and security headers. One of the first things I checked afterwards was whether /.well-known/ was still reachable without a redirect. It's easy to focus on the headers and miss a rewrite rule that breaks the next AutoSSL run, weeks later, when nobody is looking.

I also don't assume the issuer or remaining lifetime from what the host says. I read them in SSL/TLS Status or with openssl.

The same concern applies to Laravel apps, where the document root, the public directory and the rewrite rules all have to agree. For related checks on exposed files, server configuration and HTTPS, see the website security checklist for cPanel.

Should you act now?

If your certificate is valid and AutoSSL is working, there's no reason to reissue it manually just because lifetimes are changing.

Do check these now:

AutoSSL is enabled, and you know the certificate's actual expiry date.
No unused or misconfigured domains are included on the certificate.
DNS, including AAAA records, is correct for every active hostname.
The .well-known path serves real files without redirects (use the test file above).
Cloudflare redirects allow validation, if the logs show HTTP DCV failures.
Expiry alerts are on and reach an inbox someone actually reads.

If cPanel reports a rate limit: stop forcing renewals. Fix the validation problem first, then wait for the retry time shown in the error, or ask your host to review it.

Wildcard certificates (*.example.com): Let's Encrypt only validates wildcards through DNS (DNS-01), not HTTP files. In cPanel, that works only when the domain's DNS is managed on the cPanel server.

If cPanel shows "This feature is not available to your account": your host has disabled AutoSSL or SSL management in your package. That's a hosting plan setting, not a validation failure. Ask the host to enable it.

FAQ

How long before expiry does cPanel AutoSSL renew?

For Let's Encrypt certificates, AutoSSL starts trying within 29 days of expiry. For legacy cPanel/Sectigo certificates, it was 15 days. Issuance still depends on passing domain validation and on rate limits. A certificate with more than 29 days left hasn't failed to renew; it simply isn't due yet.

Can I force AutoSSL renewal without WHM access?

Yes, if your host allows it. Click Run AutoSSL in SSL/TLS Status (or the Status tab of SSL/TLS Certificates), or run uapi SSL start_autossl_check in Terminal. If neither option is available, ask your host to enable the feature or run the check for your account.

Does Cloudflare replace my cPanel origin SSL certificate?

No. Cloudflare provides the certificate visitors see at its edge, but Full (strict) mode still needs a valid certificate on your server. An expired origin certificate causes Cloudflare error 526 even while the edge certificate is fine.

Why does AutoSSL fail even though my website works?

A working homepage doesn't prove that validation works. DNS may resolve through a proxy, an AAAA record may point to an old server, a subdomain on the certificate may point elsewhere, or a rewrite rule may hide the validation files. Check the AutoSSL log for the exact hostname and validation method that failed.

If cPanel AutoSSL is not renewing, start with the DCV error, find the exact failing hostname, test its validation path, and rerun AutoSSL only after fixing the cause.