Every account's website gets a certificate for its own domain. Several things on the server do not use those certificates at all. They identify themselves with the server's own hostname.
What uses it
The control panel and WHM logins. Webmail. And the mail server that customers' mail clients connect to for sending and collecting mail.
When the hostname certificate is missing, expired or self-signed, all of those produce warnings, while every website on the machine remains perfectly secure.
That disconnect is why this fault is diagnosed slowly. The report is "my email says the server is not trusted", and every check of the website comes back clean.
The hostname has to be right first
In WHM, Networking Setup → Change Hostname.
Three requirements, and each of them breaks certificate issuance when unmet.
It must be a fully qualified name: server1.example.com, not server1.
It must resolve to this server, because issuance works by fetching a validation request over that name.
It must not be a domain a customer is hosting. Using a customer's domain as the machine's hostname causes conflicts in mail routing that are genuinely confusing to unpick later, and it means the machine's identity depends on a domain you do not control.
The convention is a subdomain of your own company domain, used for nothing else.
Issuing the certificate
AutoSSL covers the hostname alongside customer domains, provided the hostname resolves here and the validation request can be served.
When it is skipped, the AutoSSL log says which name failed and why, nearly always that the name does not resolve to this server, or that something is intercepting the validation request. Managing AutoSSL in WHM deals with both.
The services then need to be told to use it, which WHM handles, but a certificate installed while a service was running may not be in use until that service reloads.
Check what is actually being presented
openssl s_client -connect server1.example.com:2083 -servername server1.example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -dates openssl s_client -connect server1.example.com:993 -servername server1.example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -dates
Port 2083 is the control panel; 993 is mail collection. They can differ; a certificate renewed for the panel while the mail server still presents the old one is a real and confusing state, and the fix is reloading the mail service.
Checking a certificate from the command line walks through reading the output.
Tell customers to use the hostname
This is the practical half.
Customers naturally configure mail.theirdomain.com in their mail client. That name is only covered if their own certificate includes it, and even then the server may present the hostname certificate instead.
Giving customers the server hostname for incoming and outgoing mail avoids the warning entirely, because that is the name on the certificate being presented.
It looks less tidy and it works. Configuring email in Outlook goes into the settings customers are entering, and SSL for subdomains, addon domains and mail walks through the alternative of covering their mail name properly.
Renewal fails silently
Like any automatic renewal, the failure produces nothing until the certificate expires, at which point every customer's mail client warns at once, and the tickets arrive together.
Monitor the hostname's expiry the same way you would a customer's, and alert on it well ahead:
echo | openssl s_client -connect server1.example.com:993 2>/dev/null | openssl x509 -noout -enddate
Where server logs live deals with finding the issuance log when it does fail.
The hostname needs forward and reverse DNS
A certificate cannot be issued for a name that does not resolve, and the reverse lookup matters for a reason that has nothing to do with certificates.
hostname -f dig server.example.com A +short dig -x 203.0.113.10 +short
All three should agree: the configured name resolves to the address, and the address resolves back to the same name. A mismatch blocks certificate issuance and, separately, damages mail delivery: receiving systems check it.
The reverse record is set by whoever controls the address rather than in your own DNS, which is why it is the half that is usually missing. Understanding PTR and reverse DNS explains requesting it.
Services keep the old certificate until restarted
Issuing a certificate does not put it into use. Each service reads it at startup and holds it, so a fresh certificate can be installed and every client still sees the expired one.
openssl s_client -connect server.example.com:993 </dev/null 2>/dev/null | openssl x509 -noout -dates openssl s_client -connect server.example.com:465 </dev/null 2>/dev/null | openssl x509 -noout -dates openssl s_client -connect server.example.com:2087 </dev/null 2>/dev/null | openssl x509 -noout -dates
Check each port rather than one, because they are served by different processes: mail retrieval, mail submission and the panel itself. One of them presenting an older date is the whole fault, and it is invisible from the interface that says the certificate is installed.
Restart the service that is behind rather than everything. There is more on reading the output in checking a certificate from the command line.
What customers see when it is wrong
The symptoms are reported as unrelated problems, which is why this takes longer to diagnose than it should.
A mail client configured with the server's hostname warns on every send and receive, and many will refuse rather than warn. Automatic configuration fails silently. Webmail and the panel warn in the browser, and the customer concludes their own domain's certificate is broken.
The distinguishing question is which name the client is connecting to. A customer using their own domain for mail needs that domain covered; one using the server hostname needs this certificate, and telling them apart is the first thing to establish. There is more in diagnosing a mail client that will not connect.
Changing the hostname is not a single setting
Renaming a server looks like one field and touches several things that fail afterwards rather than immediately.
The certificate has to be reissued for the new name. The reverse record has to be updated by whoever owns the address. Mail announces the new name in its greeting, which affects delivery until the records match. The licence is frequently tied to the address in place of the name, but any monitoring or backup system referring to the old name simply stops.
grep -rl 'oldname.example.com' /etc/ 2>/dev/null | head
Do it deliberately, with a list, and check mail delivery afterwards specifically: it is the part that degrades quietly rather than failing outright. The email deliverability tool deals with confirming it recovered.