AutoSSL issues and renews certificates for every domain on the server without anyone doing anything. When it works you never think about it, and that is the problem. The first sign of trouble is usually a customer reporting a browser warning.
Understanding what it needs makes the difference between a server that quietly stays covered and one that develops gaps.
How it decides what to cover
AutoSSL runs on a schedule and looks at every domain, subdomain and alias on the server. For each, it tries to prove control by requesting a file it placed under that domain.
If the request reaches the server and returns the file, the domain is covered. If not, it is skipped, and the skip is recorded in a log rather than announced.
That single mechanism explains nearly every failure below.
Why a domain gets skipped
It does not point here. A domain added in cPanel whose nameservers are still elsewhere cannot be verified, because the verification request goes wherever DNS says. This is the most common cause by a wide margin.
A redirect catches the verification path. An aggressive rule sending every request to HTTPS or to another domain intercepts the challenge, and AutoSSL sees a redirect instead of its file.
The document root has a rule blocking it. Directory protection or an IP restriction covering the whole site includes the verification directory.
A wildcard or CDN sits in front. Traffic reaching a proxy rather than the server means the challenge never arrives.
Reading the results properly
WHM's Manage AutoSSL screen has a logs tab, and the log is the only place a skipped domain is visible.
Do not judge coverage by the absence of complaints. Open the log after a run and look for domains listed as failed. Each one is a certificate that will expire without replacement.
There is also a per-user view showing which domains on an account are covered and which are not. That is the view to check when a client reports a warning on one subdomain while the main site is fine.
Excluding domains deliberately
Some domains should not be covered, and leaving them in produces failures on every run.
A parked domain pointed elsewhere. A subdomain used only internally. A domain a client added and abandoned.
Exclude them explicitly rather than tolerating the noise. A log full of expected failures is a log nobody reads, and the one real failure hides in it.
When a certificate exists but the site still warns
Two causes, and they look identical to a visitor.
The certificate covers the bare domain and not www, or the reverse. Both names need coverage, and AutoSSL includes both only if both resolve to the server.
The site is serving an older certificate because the new one was installed for a different document root, common after moving a domain between accounts.
Check what is actually being served rather than what WHM says is installed. From the command line:
openssl s_client -connect example.com:443 -servername example.com
That shows the certificate the server hands out, which is the only version that matters. The SSL troubleshooting guide explains reading the output.
Renewal timing
AutoSSL replaces certificates before they expire, with a margin of weeks. That margin exists so a run failing today can succeed tomorrow without anything breaking.
Which means a domain failing to renew is not urgent on the first day and is urgent within a fortnight. The log entry is the warning, and it is the only one you get.
If you manage many accounts, check the log weekly. It takes a minute and it is the whole of AutoSSL maintenance.
Third-party certificates and AutoSSL together
A domain with a purchased certificate installed is left alone by AutoSSL as long as that certificate is valid and covers the domain.
When it expires, AutoSSL will typically step in and issue a free replacement. That is usually what you want (a covered site in place of a warning) and it surprises people who expected the site to fail visibly so they would notice the renewal was due.
If you are selling certificates, that behaviour matters commercially. Know which it is doing on your server before a client asks. Free versus paid certificates goes into what the difference actually buys.
After adding a domain
AutoSSL runs on its own schedule, which can be a day away. A new domain is therefore unprotected until then.
Run it manually for that user rather than waiting. It takes a minute and it removes the window in which a client visits their new site and sees a warning.
Then confirm coverage instead of assuming it, load the site over HTTPS, both with and without www.
The order that avoids all of this
DNS first. Confirm the domain resolves to this server. Then add it in cPanel. Then run AutoSSL. Then set up any redirect to HTTPS.
Doing the redirect before the certificate exists is what produces a site that redirects every visitor to a warning page. Forcing HTTPS goes into the last step, once the rest is in place.
One name on the server is not a customer domain and fails in a way nobody connects to the websites. Service Certificates and the Server Hostname goes into it.
Watch for the renewal that quietly stops
Automatic certificates fail in a way that produces no signal until visitors see a warning, so the check has to be yours rather than the system's.
for d in example.com www.example.com mail.example.com; do
printf '%-28s ' "$d"
echo | openssl s_client -connect "$d":443 -servername "$d" 2>/dev/null \
| openssl x509 -noout -enddate 2>/dev/null || echo "baglanti yok"
done
Run that against every hostname the account serves, not just the main one. The usual failure is a single subdomain dropping out of coverage while the rest renew normally, which no summary screen highlights.
Anything with less than two weeks remaining and no sign of renewal is worth investigating immediately. The system retries, and a certificate that has failed to renew for a fortnight is usually failing for a reason that will not resolve itself.
The two checks that decide coverage
A domain is covered only if it both points here and answers the validation request, and those are separate things that fail separately.
dig +short example.com A curl -s ifconfig.me; echo curl -sI http://example.com/.well-known/acme-challenge/test | head -1
If the address returned by the first command is not this server, the domain cannot be validated here no matter what the panel is asked to do. That is the single most common reason a domain is skipped, and it is usually a domain that was moved elsewhere and nobody removed.
If the address is right and the validation path does not answer, something is intercepting it: a redirect rule, a security plugin, a maintenance mode, or a rewrite that sends everything to the application.
Certificates and the mail hostnames
Mail clients connect to a name, and that name needs to be covered or every customer sees a warning when they check mail.
dig +short mail.example.com A echo | openssl s_client -connect mail.example.com:993 -servername mail.example.com 2>/dev/null | openssl x509 -noout -subject
Two arrangements work. Cover the mail hostname for each domain, which requires that name to resolve here, or configure clients to use the server's own hostname, which has its own certificate.
Mixing them is what produces the confusing case where mail works for some customers and warns for others, depending on which settings they were given and when. Pick one and use it consistently in the instructions you send out. Service certificates and the server hostname deals with the second option.
