Certificates are issued to hostnames, and a reseller account holds a lot of hostnames. WHM is where you see all of them at once, request what is missing, and install anything you bought elsewhere.
This covers the three screens that do that work, and the order they belong in.
The three screens and what each one is for
Generate an SSL Certificate and Signing Request creates a private key and a certificate signing request. You use it when a certificate authority needs a request from you, which is every paid certificate.
Install an SSL Certificate on a Domain takes a certificate that already exists and puts it on a hostname. The certificate can come from anywhere: a purchase, another server, a renewal.
Manage SSL Hosts lists what is currently installed across the account, with the expiry date of each. It is the only one of the three that answers the question people actually have, which is what is covered and what is not.
Start from Manage SSL Hosts, not from the other two
The instinct is to start by generating something. That is backwards on an existing account.
Open Manage SSL Hosts first. You will usually find that most hostnames already have a certificate, issued automatically, renewing on their own, and needing nothing from you. What is left is a short list, and that list is the actual job.
A hostname is missing from that list for one of a small number of reasons, and they need different responses.
Why a hostname has no certificate
It does not resolve to this server. A certificate authority proves you control a domain by making a request to it. If the domain still points at the previous host, nothing you do in WHM changes the outcome. Move DNS first.
A redirect catches the verification request. A rule that sends every request to HTTPS, or to another hostname, also catches the plain HTTP request the authority makes to check the file it placed. The request never reaches the file, so verification fails while the site looks perfectly healthy.
A CAA record forbids that authority. If the domain publishes a CAA record naming other authorities, the one your server uses must refuse, and it does. This is the cause nobody looks for, because the record is correct and doing exactly what it was asked to do.
The hostname is new. Automatic issuance runs on a schedule. A subdomain created twenty minutes ago has simply not been picked up yet.
The first of those four is by far the most common, and it is the one where retrying is guaranteed not to help.
Generating a request, when you actually need one
You need a signing request only when buying a certificate. Free automatic certificates involve no request at all: the server handles the exchange itself.
The screen asks for the hostname, the organisation and the location. The hostname is the part that matters and the part that has to be exactly right, including whether it carries the www prefix. Everything else is descriptive.
What the screen produces is two things: the request, which you hand to the certificate authority, and a private key, which stays on the server. Those two belong together permanently, and that pairing is what most failed installations come down to.
Installing what comes back
The authority returns a certificate and, usually, one or more intermediate certificates. The install screen has a box for each, plus the private key.
Three things go wrong here, in descending order of frequency.
The certificate and the key do not match. This happens when a request was generated more than once and the wrong key was kept, or when a certificate is moved between servers without its key. WHM checks the pair and refuses the install, which is helpful, but the message describes a mismatch rather than explaining where the right key is.
The intermediates are missing. The install succeeds and the site works in your browser, because your browser has seen that intermediate before and fills it in from its own cache. A new visitor, or any script, gets a trust error. This is the fault that looks intermittent and is not.
The hostname does not match. A certificate issued for the bare domain does not cover the www form, and vice versa. Both are separate names and both need coverage.
Renewal is where paid and free diverge
Automatic certificates renew about thirty days before expiry with no involvement from anyone. The only thing that can go wrong is one of the four causes above appearing after the certificate was first issued: a domain moved away, a redirect rule added, a CAA record published. In each case the certificate simply stops renewing and expires quietly, which is why an expiry alert from outside the server is worth having.
A purchased certificate renews when somebody remembers. The install screen is the same, the pairing rules are the same, and the date is a diary entry rather than a mechanism.
If you are managing accounts for clients, this is the difference worth explaining to them: an automatic certificate is a system, and a purchased one is a task that somebody owns.
The mail and panel hostnames are separate
Manage SSL Hosts shows the hostnames used for websites. The server's own hostname, the one behind the control panel login, webmail and the mail server clients connect to, carries its own certificate and does not appear in a customer domain list.
That certificate expiring breaks no website at all. It shows up as a mail client that will not connect, or a browser warning on the panel address, which is why it is missed for so long. It is covered in service certificates and the server hostname.
A short working order
Open Manage SSL Hosts and read what is already covered. For anything missing, check whether the domain resolves here before anything else. Fix the cause rather than retrying. Generate a request only when buying. When installing, confirm the certificate and key are a pair, and include the intermediates. Then come back to Manage SSL Hosts and confirm the name you were working on is now listed with a sensible expiry date.
That last step takes ten seconds and is the only one that proves the work is done.
