AutoSSL not renewing in cPanel: fixes

Short answer: AutoSSL stops renewing a certificate when it cannot prove the domain is yours. That check is called domain control validation (DCV). The usual causes are a redirect or rewrite rule that blocks the validation file, DNS that no longer points at the server, a proxy such as Cloudflare in front, or the domain being excluded from AutoSSL. Read the AutoSSL log for the exact reason, fix that one thing, then run a new check from WHM or the command line.

Why does AutoSSL fail to renew a certificate?

AutoSSL asks the certificate provider (cPanel's own provider or Let's Encrypt) for a new certificate. The provider then checks that the domain is really served by this account. Per the Let's Encrypt "Challenge Types" page (see Sources), the HTTP method works by fetching a small file from /.well-known/acme-challenge/ over HTTP. cPanel's own provider uses a similar path under /.well-known/pki-validation/. DNS-based checks also exist. If the check fails for any domain on the certificate, AutoSSL logs the failure and, as cPanel's Manage AutoSSL documentation describes it, tries again on a later run. The old certificate keeps serving until it expires, so nothing looks wrong until the day visitors get a browser warning.

What are the most common causes, and what fixes each one?

Cause	What you see in the log	Fix
Redirect or rewrite rule blocks the validation path	DCV failed, HTTP 301/403/404 on the challenge file	Exempt `/.well-known/` from redirects, security plugins and WAF rules
DNS points elsewhere	Domain does not resolve to this server	Point the A record back, or remove the domain from the account
Cloudflare proxy or bot rules	Challenge file returns a Cloudflare page	Allow the validation path, or pause the proxy for the check
Domain excluded from AutoSSL	Domain is skipped	Remove it from the excluded list in WHM
Rate limit at Let's Encrypt	Too many certificates or failed validations	Wait for the limit window, then retry
A dead subdomain on the same certificate	One name fails, the rest pass	Delete the stale subdomain or its DNS record

How do I find the real error?

Do not guess. On the server, the AutoSSL logs live under /var/cpanel/logs/autossl/, one folder per run. In WHM, open Manage AutoSSL and look at the Logs tab. Each domain has a line saying why it was skipped or failed. If you only have cPanel access, open SSL/TLS Status, which shows which domains have a valid certificate and lets you run AutoSSL for the account.

To see what the visitor sees, run this from any machine:

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

It prints notBefore, notAfter and the issuer. If notAfter is within a few days and the issuer is the AutoSSL provider, renewal is overdue and the log will say why. To test the validation path the way the provider does, run:

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

A 404 Not Found straight from the web server is fine, because the file does not exist and nothing blocked the path. A 301 to a page that then errors, a 403, or a Cloudflare or login page in the response is the problem.

What are the exact fix steps?

Read the log line for the failing domain and note the HTTP status or DNS message.
Run the curl test above against the failing domain and compare the response to what the log reported.
In WordPress, check your .htaccess file and any security or redirect plugin. Force-HTTPS rules and "block hidden files" rules are the usual culprits. Make sure the .well-known path is allowed through.
If the site is behind Cloudflare, confirm the challenge file is not being answered by a Cloudflare challenge page. Cloudflare's edge certificate documentation covers how its certificates and SSL modes interact with an origin certificate.
Check the domain and every subdomain on the certificate still resolve to this server. Remove records for names that no longer exist.
In WHM, check Manage AutoSSL to confirm the domain is not on the excluded list.
Re-run AutoSSL for the account, for example /usr/local/cpanel/bin/autossl_check --user=USERNAME, and read the new log.

If the log mentions a rate limit, do not rely on any number quoted in a blog post, including this one. Let's Encrypt publishes the current limits on its rate limits page, and repeated failed attempts can make things worse, so fix the cause before retrying.

What does an expired certificate look like in a real case?

A well-known public example is the expiry of Let's Encrypt's old root certificate, DST Root CA X3, on 30 September 2021. Let's Encrypt published a page about it (listed in Sources) that, as we read it, warned some older devices and software could stop trusting sites that used its certificates. That case was not an AutoSSL failure and it has nothing to do with quietwatch or any quietwatch customer. It shows the same pattern: the date passes and clients that cannot validate the chain show errors, whether or not the site owner changed anything. You can reproduce the check on any domain you manage with the openssl command above and read notAfter yourself.

Can a broken certificate affect Googlebot, the sitemap and Search Console?

It can, though you should confirm the specifics rather than assume them. Google's robots.txt documentation describes how Googlebot treats a robots.txt file it cannot fetch, so check its current wording before you tell a client what to expect. Google's sitemaps overview explains how a sitemap is fetched and read, and Search Console's page indexing report is where Google says what it could and could not index. After you fix a certificate, open Search Console for the client site and look for new fetch or indexing errors.

While you are in the .htaccess file or a security plugin, also check that nothing added a blanket noindex rule. Google's robots meta tag documentation lists noindex as a rule that can be sent in an X-Robots-Tag HTTP header, so a maintenance or staging setting can hide pages without any visible sign on the page itself.

What do I tell the client?

Keep it short and honest. Something like: "The automatic renewal of your site's security certificate failed because a redirect rule blocked the check. It is fixed and the new certificate is in place. Nothing was lost." If the certificate had already expired, say so, give the time window, and note that browsers showed a warning during it. Then say what you changed so it does not happen again, for example that the validation path is now exempt from redirects.

Check expiry on every client site, not only the ones you remember. Our domain and SSL expiry checker shows the expiry date for any domain in seconds.

How does quietwatch catch this daily?

quietwatch reads the certificate on every client site each day and warns you well before it expires, so a silent AutoSSL failure shows up as an alert instead of a client phone call. You can see what quietwatch checks every day. The free tool above is the place to start: paste in a domain and see its dates.

Sources

All posts · The fourteen checks

AutoSSL not renewing certificates in cPanel? Here is the fix