Buying a certificate starts with generating a key pair and a signing request. The certificate authority signs the request and returns a certificate; the private key never leaves your server, and that is the whole security model.
Understanding which half is secret is what prevents the mistakes below.
What each file is
The private key stays on your server. It is what proves the certificate is yours. Anyone holding it can impersonate your site.
The CSR contains your public key and your details. It is sent to the authority and is not sensitive.
The certificate comes back signed and is public: every visitor receives a copy.
One rule follows: the key is secret, everything else is not. A key emailed to you by anyone is a key that has been in a mailbox.
Generating them in cPanel
Under SSL/TLS, use Private Keys to generate a key, then Certificate Signing Requests to create the CSR from it. cPanel stores both.
2048-bit RSA is the safe default and is accepted everywhere. 4096-bit is stronger and slightly slower for every connection; the practical benefit for a website is small.
ECDSA keys are faster and smaller and are widely supported now. If your authority offers them, they are a reasonable choice, and RSA remains the option that never surprises anyone.
Filling in the CSR
The common name is the domain. Get this exactly right: www.example.com and example.com are different names, and the certificate covers what you asked for.
For a wildcard, the common name is *.example.com.
The organisation fields matter only for validated certificates. For a domain-validated certificate they are not checked, so approximate values do no harm, but for an organisation-validated one they must match your registered details exactly, or validation stalls and nobody tells you why. Certificate types explained goes into which you are buying.
Do not set a passphrase on a key used by a web server. The server cannot type it at boot, so the site fails to start after a reboot and the cause is not obvious at three in the morning.
From the command line
openssl req -new -newkey rsa:2048 -nodes \ -keyout example.com.key -out example.com.csr
-nodes means no passphrase, which is what you want for a server key.
Then check what you generated before sending it:
openssl req -in example.com.csr -noout -text
Confirm the common name is right. A CSR with a typo produces a certificate for a domain you do not have, and reissuing is a support conversation you can avoid by reading one line.
The key and certificate must match
A certificate only works with the key its CSR was generated from. If you generated a second key while waiting, the returned certificate does not match it.
Compare the two:
openssl x509 -noout -modulus -in example.com.crt | openssl md5 openssl rsa -noout -modulus -in example.com.key | openssl md5
The two hashes must be identical. Different hashes is the explanation for "the certificate will not install" more often than anything else, and the fix is to find the right key, or reissue against a new CSR.
Losing the key means reissuing
There is no recovery. The authority cannot send you a replacement, because they never had it.
Back it up when you generate it, somewhere that is not only on the server it protects. And keep that backup as restricted as the original. A key in a shared folder is a key several people have.
On the server, the key file should be readable only by root or by the account that owns it, with permissions of 600. A world-readable key is the same as a published one. For checking, see understanding file permissions.
Never reuse a key across servers
Copying a key to a second server doubles the number of machines whose compromise exposes your site.
Generate a new key per server. Certificates can be reissued for the same names as many times as you need, and the cost of doing it properly is a few minutes.
The same applies to reissuing after a compromise: generate a new key and reissue against a new CSR. Reissuing with the same key leaves the attacker holding a working key for the new certificate.
File formats
PEM is the text format beginning -----BEGIN CERTIFICATE-----, and it is what cPanel and most Linux servers use.
PKCS#12 or PFX bundles the certificate, chain and key into one password-protected file, used by Windows and some appliances.
Converting between them is straightforward with openssl. What matters is knowing that a PFX contains the private key, so sending one to somebody sends them your key. A distinction that is easy to miss when it looks like just another certificate file.
After installing
Reload the web server, then verify from outside rather than trusting the interface.
Check the names the certificate actually covers and that the chain is complete; a certificate installed without its intermediates works in your browser and fails elsewhere. There is more on that specifically in understanding the certificate chain.
Then delete any CSR and key files you copied somewhere temporary while working. A key left in a downloads folder or, worse, inside public_html, undoes everything above.
Moving an existing certificate means handling the key again, with one check that prevents the usual failure. How to Move an SSL Certificate to a New Server has the detail.
Generate the key with the right strength
Defaults vary by tool and by age, and a key generated by an old command may be weaker than anything an authority will now issue against.
openssl req -new -newkey rsa:2048 -nodes -keyout example.key -out example.csr openssl ecparam -genkey -name prime256v1 -out example-ec.key openssl req -new -key example-ec.key -out example-ec.csr openssl req -in example.csr -noout -text | grep -E 'Public-Key|Signature Algorithm|Subject:'
Read the request back before submitting it. The key size, the algorithm and the subject line are all visible there, and a mistake found now costs nothing.
The elliptic option produces smaller keys and faster handshakes at equivalent strength, and is well supported. It is worth choosing deliberately rather than accepting whatever the panel defaults to.
Put the names in the request, not just the subject
The common name field is effectively ignored by modern clients, which read the alternative names list instead.
openssl req -new -key example.key -out example.csr \ -subj "/CN=example.com" \ -addext "subjectAltName=DNS:example.com,DNS:www.example.com" openssl req -in example.csr -noout -text | grep -A1 'Subject Alternative Name'
A request naming only the bare domain produces a certificate that warns on the prefixed form, which is the most common version of a certificate that was issued correctly and does not work.
List every hostname the certificate must cover, including the ones you consider aliases. Adding one afterwards means a reissue rather than an edit.
Keep the private key private, including from your own tooling
The key is the certificate. Anything that reads it can impersonate the site, and it ends up in more places than people intend.
ls -l example.key chmod 600 example.key grep -rl 'BEGIN.*PRIVATE KEY' ~/ 2>/dev/null | head grep -rl 'BEGIN.*PRIVATE KEY' /tmp /var/tmp 2>/dev/null | head
The last two commands find copies. Keys routinely accumulate in a downloads folder, a temporary directory, an email attachment or a version control repository, and each copy is a full compromise waiting to be found.
Generate the key where the certificate will be used, so it never travels. Where that is not possible, move it once, confirm it works, and delete every intermediate copy including the one in whatever transferred it. Moving an SSL certificate to a new server covers doing that safely.