Reviewing WHM AutoSSL Logs Weekly to Catch Domains Before Renewal Fails

AutoSSL in WHM is easy to forget about because most of the time it just works. When it doesn't, it rarely makes noise. A domain gets skipped, a new certificate is issued without one of the names, or a renewal is quietly deferred. Nobody notices until a browser or mail client starts warning about an expired certificate on mail.example.com or an old addon domain. The AutoSSL logs usually recorded the problem weeks earlier. Reading them once a week is how you catch it while there is still time. This guide stays on the command line. You find the latest run, pull out the failures, check them against live DNS, fix or remove the domain, then confirm the result. For a deeper walkthrough of why individual domains get skipped, see Membaca Log AutoSSL cPanel untuk Tahu Kenapa Domain Dilewati Saat Renewal.

Finding the latest AutoSSL run on disk

In the WHM interface the logs live under SSL/TLS, then Manage AutoSSL, on the Logs tab. That view is fine for one account. For a weekly sweep across the whole server, the files on disk are faster. Each AutoSSL run writes its own timestamped directory under /var/cpanel/logs/autossl/. The file names inside can differ between cPanel versions, so it is safer to grep the whole directory than to rely on a specific file name.

BASH

# Show the five most recent AutoSSL runs, newest first
ls -1t /var/cpanel/logs/autossl/ | head -n 5

# Pull warning and error lines from the latest run
latest=$(ls -1t /var/cpanel/logs/autossl/ | head -n 1)
grep -rhiE 'error|warn|fail' /var/cpanel/logs/autossl/$latest/ | head -n 60

You are not reading every line here. You want the list of names that failed validation and the reason given for each. On a busy server the same few domains tend to show up week after week. Those are the ones that will eventually become an expired-certificate ticket. One thing to keep in mind is that a run with failures can still issue a certificate. AutoSSL typically requests a certificate for the names that passed and leaves out the rest. In some cases it also holds off replacing a current certificate that covers more names, until that certificate gets close to expiry. Either way, the site looks fine today and the failure stays hidden until the old certificate runs out.

Reading the DCV messages

DCV stands for domain control validation. It is the step where the certificate provider confirms that the server really controls each name before signing a certificate for it. AutoSSL typically tries HTTP validation first. It places a small file under the domain's .well-known path and checks that the file can be fetched over the public internet. Depending on setup and provider, it can also use DNS validation, which only works if this server is authoritative for the domain's DNS zone. The exact wording of these messages changes between cPanel versions, so treat the table below as patterns to recognize, not strings to grep for literally.

What the log line is saying	Usual cause	What to check
The name resolves to an IP this server does not use	DNS was moved to another host, or the record points at a proxy or an old server	Public A/AAAA record vs. the server's IPs
The name does not resolve at all	The domain expired, the record was deleted, or there is a typo in an alias	`dig` against a public resolver, plus WHOIS status
The HTTP fetch returned the wrong content, a redirect, or an error	Redirect rules, a security plugin, or a proxy blocking `.well-known`	The site's rewrite rules and proxy settings
DNS validation is not possible because this server is not the authority	The zone is hosted elsewhere, so the local DNS cannot publish the challenge	`dig NS` for the domain

Mail and service subdomains deserve special attention. cPanel tries to cover names like mail., webmail., and cpanel. for each domain. When a customer moves their email to another provider and repoints mail. there, that name starts failing on every run. Their website still loads with a valid certificate, so they don't connect the warning in their mail client to anything on the hosting side. That gap between "the site is fine" and "my email says the certificate is invalid" is where a lot of SSL tickets come from.

Checking where the failing names really point

Before changing anything, confirm what the internet sees. Query a public resolver instead of the server's default one. A cPanel server often answers from its own local zone, and that zone can still hold the old records even after the domain's real nameservers have moved somewhere else.

BASH

# IPs configured on this server
hostname -I

# Compare each failing name against public DNS
for d in example.com www.example.com mail.example.com old-addon.example.net; do
  printf '%-32s A: %s
' "d" "(dig +short A $d @1.1.1.1 | tr '
' ' ')"
done

# Which nameservers are actually authoritative for the zone
dig +short NS example.com @1.1.1.1

When you read the results, there are four common cases:

Matches a server IP. The DNS side is fine, and the failure is somewhere in the HTTP path.
Points somewhere else. The name has moved away from this server.
Returns nothing. The name is gone, or the domain itself may have lapsed.
Nameservers are not this server. DNS validation cannot work from here no matter what the local zone says.

If the record points at a CDN or proxy, the result depends on how that proxy handles the validation request. Sometimes HTTP validation passes through, and sometimes it doesn't. Test it rather than assume.

Deciding whether to fix, exclude, or remove

Every failing name falls into one of three situations, and each one has a different fix. The name should point here but doesn't. This is usually a stale record after a migration, or an IP change that never reached the external DNS provider. Correct the record at whichever nameservers are authoritative, wait for the TTL to expire, and the next run should pick it up. The name intentionally lives elsewhere. A common example is a mail. subdomain that now belongs to a separate mail provider. Keep the record as it is and exclude that name from AutoSSL in the account's SSL/TLS Status page in cPanel. That stops it from failing on every run, and it makes the log quieter, so real problems stand out. The domain is abandoned. This is typically an addon or alias domain the customer stopped renewing years ago. Removing it from the account is the clean fix, but it is not something to do silently.

Warning: Removing an addon or alias domain deletes its virtual host and DNS zone on the server. Depending on the version and the options chosen, it can also affect the document root. Before you remove anything:

Confirm with the account owner that the domain is no longer needed.

Make sure a recent backup of the account exists.

Then remove the domain.

If the owner is not sure, excluding the domain from AutoSSL is the reversible option.

From a support point of view, the exclude-or-remove decision is worth writing into the ticket. Otherwise the next engineer who sees the same failure in the log starts the investigation from scratch.

Rerunning AutoSSL and confirming the live certificate

After a fix, you don't have to wait for the next scheduled run. Trigger a check for just that account, then look at the certificate the server actually serves. Don't rely only on what the interface reports.

BASH

# Re-run AutoSSL for one cPanel account (confirm flags with --help on your version)
/usr/local/cpanel/bin/autossl_check --user=exampleuser

# Check expiry and covered names on the live HTTPS certificate
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -enddate -ext subjectAltName

# Same check for the mail service (IMAPS) using SNI
echo | openssl s_client -connect mail.example.com:993 -servername mail.example.com 2>/dev/null \
  | openssl x509 -noout -enddate -ext subjectAltName

The notAfter date should have moved forward. The Subject Alternative Name list should now include the name that was failing, unless you excluded it on purpose. The -ext option needs OpenSSL 1.1.1 or newer. On older systems, use -text and look for the lines that start with DNS:. If the new certificate shows up on 443 but not on 993, the web side is done. The remaining issue is with the mail service's certificate, which is a separate check. Then run the grep from the first section again on the newest log directory. The domain you fixed should no longer appear. If it still does, compare the new reason with the old one. A message that changes from "resolves elsewhere" to an HTTP fetch error means you fixed DNS and uncovered the next problem, which counts as progress. A weekly routine doesn't need to be more than this. Grep the latest run, check the few names that keep failing against public DNS, and decide for each one whether to fix, exclude, or remove it. WHM's Contact Manager can also email AutoSSL notifications, which helps as a backup, but a short manual pass is what turns a long list of failures into a decision for each domain. Every name you resolve now is one less expired-certificate ticket a few months from now, and the cleaner the log gets, the easier the next real problem is to spot.