A certificate is issued to hostnames, not to an account. That single fact explains most of the confusion about why some addresses on a hosting account are secure and others are not.
Count the names, not the sites
An ordinary account has more hostnames than people expect.
The main domain and its www form; two names. Each addon domain and its www. Two more each. Every subdomain. And the mail hostname customers put in their mail clients.
Every one of those needs to be on a certificate, or a visitor reaching that name over HTTPS gets a warning.
The bare domain and www
These are different names. A certificate covering only one produces a warning for exactly the visitors who typed the other form.
It is easy to miss because you personally always type the same form. The check is direct, load both, in a browser that has not been to the site recently, or from the command line: checking a certificate from the command line shows the full name list in one command.
Subdomains created later
This is the most common version of the problem.
A certificate is issued covering the names that existed at the time. Someone creates shop.example.com a month later. It is not on the certificate, because certificates do not update themselves when a subdomain appears.
AutoSSL picks it up on its next run, which may be a day away. If the subdomain is needed immediately, run issuance manually rather than waiting. Managing AutoSSL in WHM walks through triggering it.
A wildcard covers subdomains created later without reissuing, which is its real advantage over convenience: one level of subdomain, automatically, forever. Wildcard and multi-domain certificates covers the limits.
Why a domain gets skipped silently
Two causes, both producing the same result: the domain is listed in the panel, and there is no certificate for it.
The domain does not point at this server. Validation works by fetching a file over the domain. If the domain resolves elsewhere, the fetch reaches the other server, fails, and the domain is skipped. This is normal for a domain added in advance of its DNS being changed, and it stays broken until someone notices the DNS was never updated.
Something intercepts the validation request. A redirect rule that sends everything to HTTPS or to another domain will also redirect the validation request, which then does not return the expected file. A site-wide redirect added before the certificate existed produces exactly this deadlock.
The AutoSSL log states which domain was skipped and why, in plain language. It is the fastest answer available and it is the one people skip. Where server logs live explains finding it.
Mail is the one that gets forgotten
Mail clients connect to a hostname over TLS, and that hostname needs to be on a certificate too.
The failure is invisible from the website: everything looks secure, and customers get "cannot verify the identity of the server" when setting up mail. Many click through it, which is worse than the error, because it teaches them to dismiss certificate warnings.
The fix is to make sure the mail hostname is covered, and to have customers configure that exact hostname rather than their own domain if the two differ. Configuring email in Outlook deals with the settings customers are actually entering.
Addon domains have their own timetable
Each addon domain is validated independently. One can be covered while another is not, on the same account, on the same day.
So checking the main site proves nothing about the others. Check each domain the account serves. It is a few seconds each and it is the only way to find the one that quietly expired.
After it works, force it
A certificate that exists does nothing for visitors who arrive over plain HTTP. Redirect them, forcing HTTPS goes into doing it without creating the loop, and without breaking the validation request the next renewal will need.
List every name the account actually serves
The counting problem is easier with the list in front of you. From the server:
ls /var/cpanel/userdata/USERNAME/ | grep -v '_SSL\|cache\|main'
From outside, the certificate itself tells you what is covered:
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \ | openssl x509 -noout -text | grep -A1 'Subject Alternative Name'
Comparing the two lists is the whole exercise. Names the account serves that do not appear on the certificate are the ones producing warnings, and they are almost never the main site.
Check them all at once
for h in example.com www.example.com shop.example.com mail.example.com; do
d=$(echo | openssl s_client -connect "$h":443 -servername "$h" 2>/dev/null \
| openssl x509 -noout -enddate 2>/dev/null | cut -d= -f2)
printf '%-30s %s\n' "$h" "${d:-NO CERTIFICATE}"
done
Run monthly, this finds the subdomain that quietly stopped renewing before a visitor does. Checking a certificate from the command line goes over reading the rest of what it returns.
Wildcards, and what they do not cover
A wildcard certificate removes the reissue problem for subdomains created later, which is its real advantage.
Two limits matter. It covers one level only, *.example.com matches shop.example.com and not uk.shop.example.com. And it does not cover the bare domain, which must be listed separately.
A wildcard also needs DNS-based validation, which means either a provider integration or a manual step at each renewal, and a manual step at renewal is a certificate that will eventually expire. Wildcard and multi-domain certificates goes over the trade, and wildcard DNS records goes over keeping the two in step.
The redirect that blocks its own certificate
A specific deadlock worth recognising, because it is self-inflicted and confusing.
Validation works by fetching a file over plain HTTP at a known path. A site-wide rule that redirects everything, to HTTPS, to another domain, or to a maintenance page, redirects that request too, so the check fails and the certificate is never issued.
The domain then has no certificate, and the redirect to HTTPS sends visitors to a warning.
The fix is to exclude the validation path from the redirect:
RewriteCond %{REQUEST_URI} !^/\.well-known/
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]
Forcing HTTPS explains the rule, and this exclusion belongs in it from the start rather than after a renewal fails.