On Ahosting, SSL certificates are issued automatically. In most cases installing one means confirming it already happened, and the work you actually do is on the domains where automatic issuance failed, which is nearly always a DNS problem instead of a certificate problem.
This covers checking status, running issuance manually, installing a certificate you bought elsewhere, and the failures worth recognising.
Check what you already have
In cPanel, open SSL/TLS Status under Security. It lists every domain and subdomain on the account with its certificate state.
Green with a valid certificate means done. There is nothing to install. Do this before anything else; a fair amount of effort gets spent installing certificates that were already there.
Anything not covered is what you work on. Note that new subdomains and addon domains are not automatically covered by an existing certificate unless it is a wildcard.
Run AutoSSL for uncovered domains
Select the domains showing no certificate and choose the option to run AutoSSL on them. Issuance normally completes within a few minutes.
The requirement is that the domain resolves to this server. The certificate authority verifies control by requesting something from the domain, so if it points somewhere else (or nowhere) verification fails.
That makes the order fixed: DNS first, certificate second. Requesting a certificate for a domain that has not moved yet fails every time, and retrying without fixing DNS fails identically.
Installing a certificate you bought elsewhere
If you have a commercial certificate, the process is manual and has three parts.
Generate a CSR. In cPanel, open SSL/TLS then Generate a Certificate Signing Request. Fill in the domain and organisation details. This produces a CSR to give the authority and a private key that stays on the server, never send the private key to anyone.
Give the CSR to the authority and complete their validation. They return the certificate, usually with a CA bundle of intermediate certificates.
Install it. Open SSL/TLS then Install and Manage SSL for your site. Paste the certificate, and paste the CA bundle into its field.
The CA bundle is the part people skip, and it produces a specific failure: the site works in your browser, which happens to have the intermediate cached, and shows a certificate error on other devices. If a certificate works for you and not for a client, this is the first thing to check.
Confirm it is actually working
Load the site over https:// in a private window and check the padlock.
Test every name the site answers on. A certificate covering example.com but not www.example.com shows a warning to everyone who types the www form, and that is easy to miss when you always use the bare domain yourself.
Then check from another device or network. Intermediate certificate problems are invisible on the machine you did the work on.
Installing is not finishing
A valid certificate does not mean the site uses it. Two more steps complete the job.
Redirect HTTP to HTTPS, so old links and indexed URLs move across rather than continuing to serve the insecure version, forcing HTTPS.
Clear mixed content, so the page is not pulling images or scripts over HTTP and breaking the padlock, fixing mixed content warnings.
For WordPress there is an additional step inside the application: the site address must be changed to the HTTPS form, or WordPress keeps generating HTTP links. Setting up SSL in WordPress explains it.
Common failures
AutoSSL fails repeatedly. The domain does not resolve to this server. Check its nameservers before anything else.
Certificate warning naming a different domain. The certificate does not cover the name being used: usually www versus bare. Reissue covering both.
Works on your machine, fails elsewhere. Missing CA bundle.
Padlock shows a warning triangle. Not a certificate problem. That is mixed content.
Certificate expired. If it was automatic, issuance has been failing quietly, usually because DNS changed. If it was commercial, nobody renewed it. Renewing your SSL certificate goes over both.
A subdomain has no certificate. Expected. Run issuance for that name, or use a wildcard.
For the background on what the certificate is proving, What is an SSL Certificate and Why Your Website Needs One goes over it from the beginning.
An account usually has more hostnames than it has sites, and the ones that get missed follow a pattern. There is more on counting them in SSL for Subdomains, Addon Domains and Mail.
When the certificate already exists elsewhere, three files have to travel together and one of them must never be emailed. For that, see How to Move an SSL Certificate to a New Server.
Check the certificate is being served on every name
Installation applies to a domain, and an account with several is easy to leave half covered.
for d in example.com www.example.com shop.example.com mail.example.com; do printf '%-26s %s\n' "$d" "$(echo | openssl s_client -connect "$d":443 -servername "$d" 2>/dev/null | openssl x509 -noout -enddate 2>/dev/null || echo 'yok')" done
Every name a visitor might type has to be covered, including the prefixed form and any subdomain in use. A certificate covering the bare domain only produces a warning on the address most people actually visit.
Different expiry dates across names mean they were issued separately, which is workable and means two renewal dates to track rather than one.
What to do when the browser still warns
A certificate that is installed and still warning has a small number of causes, and one command distinguishes them.
echo | openssl s_client -connect example.com:443 -servername example.com 2>&1 | grep -E 'Verify return code|subject=|issuer='
A name mismatch means the certificate does not cover what was typed. A verification failure at depth one means the intermediate is missing. A date failure means it expired or has not started.
If the command reports the certificate as valid and the browser still complains, the page is loading something insecurely rather than the certificate being wrong, which is a different fix entirely. Fixing mixed content warnings deals with that case.