Skip to content
Back to Blog
SSL & Security8 min read

Install SSL cPanel Checklist: 12 Steps Before Go-Live

A step-by-step SSL installation checklist for cPanel servers—covering certificate validation, Apache config, AutoSSL setup, and common pitfalls to catch before you deploy.

Written by Abdul AbrorTechnical Hosting Support Engineer
Install SSL cPanel Checklist: 12 Steps Before Go-Live
On this page

You've bought the certificate, uploaded the files, and clicked Install. But SSL deployments still break in production—mixed content warnings, chain issues, mail client errors. I've restored more than a few sites at 2 a.m. because someone skipped a verification step.

This checklist covers the twelve items you should verify before flipping the switch on a new SSL certificate in cPanel. Follow it in order and you'll catch the gotchas that cause rollbacks.

1. Verify certificate files are complete

You need three PEM-encoded text blocks: the certificate (CRT), the private key (KEY), and the CA bundle (sometimes called intermediate or chain). Open each file in a text editor.

The certificate starts with -----BEGIN CERTIFICATE----- and ends with -----END CERTIFICATE-----. Same structure for the key, but it says PRIVATE KEY. The CA bundle contains one or more certificates in the same format, stacked.

Missing the CA bundle is the most common mistake. Browsers will throw trust errors even though the certificate itself is valid. If your CA didn't provide a bundle file separately, check their documentation—sometimes it's concatenated at the end of the certificate file.

2. Match the private key to the certificate

A certificate is cryptographically tied to its private key. If you upload the wrong key, Apache will start but clients will see handshake failures.

Run these two commands via SSH and compare the MD5 hashes:

openssl x509 -noout -modulus -in certificate.crt | openssl md5
openssl rsa -noout -modulus -in private.key | openssl md5

Both hashes must match exactly. If they don't, you've either grabbed the wrong key file or regenerated the CSR without saving the original key.

3. Check the certificate common name and SANs

Open the certificate in WHM under SSL/TLS → View Certificate or decode it on the command line:

openssl x509 -in certificate.crt -text -noout

Look at the Common Name (CN) and the Subject Alternative Name (SAN) extension. The domain you're securing must appear in the SAN list. Modern browsers ignore the CN and only check SANs.

If you ordered a wildcard cert (*.example.com), remember it does not cover the bare domain (example.com) unless that's also listed as a SAN. You'll need both entries for typical setups.

4. Confirm the certificate is not expired or not-yet-valid

Still in the decoded output, find Not Before and Not After. The current date must fall between those two timestamps.

I've seen certificates uploaded weeks before their validity period started because the CA issued them early. The handshake will fail until the Not Before date passes. Set a calendar reminder if you're staging ahead of time.

5. Install the certificate in WHM or cPanel SSL/TLS interface

In WHM, go to SSL/TLS → Install an SSL Certificate on a Domain. Paste the certificate, private key, and CA bundle into the corresponding boxes. WHM will auto-detect the domain if the certificate is valid.

Alternatively, if you're working in a user's cPanel (not root), navigate to Security → SSL/TLS → Manage SSL Sites. Same process: paste all three parts and click Install.

cPanel will write the certificate to /var/cpanel/ssl/installed/certs/, the key to /var/cpanel/ssl/installed/keys/, and update the Apache virtual host config.

6. Verify the Apache virtual host includes the certificate paths

SSH into the server and inspect the domain's virtual host file. For a user account, it's typically in /etc/apache2/conf.d/userdata/ssl/2_4/username/domain.com/. The exact path depends on your Apache version and EasyApache profile.

Look for these directives inside the <VirtualHost *:443> block:

SSLEngine on
SSLCertificateFile /var/cpanel/ssl/installed/certs/example.com.crt
SSLCertificateKeyFile /var/cpanel/ssl/installed/keys/example.com.key
SSLCertificateChainFile /var/cpanel/ssl/installed/cabundles/example.com.cabundle

If they're missing or pointing to old files, the install didn't complete. Rebuild the config:

/scripts/rebuildhttpdconf
systemctl restart httpd

7. Test the SSL handshake from the command line

Before you touch DNS or tell users to visit the HTTPS URL, verify the server is actually serving the certificate:

openssl s_client -connect example.com:443 -servername example.com

You'll see the certificate chain, cipher negotiation, and a Verify return code. A code of 0 means success. Anything else—like 20 (unable to get local issuer certificate) or 21 (unable to verify the first certificate)—means the chain is incomplete.

Press Ctrl+C to exit. This test is faster than waiting for a browser cache to clear.

8. Run an external SSL validation tool

Internal tests can miss issues that only appear from the public internet—firewall rules, SNI problems, or stale CDN caches. Use an online checker like SSL Labs Server Test or WhyNoPadlock.

These tools will flag:

  • Missing intermediate certificates
  • Weak cipher suites
  • TLS version misconfigurations
  • Certificate name mismatches

Aim for an A or A+ grade. A B is acceptable if you're supporting very old clients, but anything lower usually means a fixable config problem.

9. Configure AutoSSL or manual renewals

If you're using a Let's Encrypt certificate via cPanel AutoSSL, verify it's enabled for the domain. In WHM, go to SSL/TLS → Manage AutoSSL and check the user's account. The domain should appear in the AutoSSL queue with a green checkmark.

For commercial certificates, set a calendar reminder 30 days before expiration. Most CAs email renewal notices, but those go to the admin contact in WHOIS—make sure that address is monitored.

AutoSSL will not replace a manually installed commercial certificate. If you want to switch back to Let's Encrypt later, delete the installed cert first.

10. Set up HTTP to HTTPS redirects

Clients will still hit the HTTP version of your site unless you force a redirect. Add this block to .htaccess in the document root:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]

Or if you prefer to set it at the virtual host level, add a Redirect permanent directive in the <VirtualHost *:80> block and rebuild Apache.

Test both http://example.com and http://www.example.com to confirm the redirect works for all variants.

11. Check for mixed content warnings in the browser

Load your site over HTTPS and open the browser's developer console. Look for warnings about insecure resources—images, scripts, or stylesheets loaded over HTTP.

Common culprits:

  • Hardcoded http:// URLs in templates or database content
  • Third-party widgets that don't support HTTPS
  • CDN resources still pointing to HTTP endpoints

WordPress sites can use the Better Search Replace plugin to update URLs in the database. For static sites, grep your document root:

grep -r 'http://' /home/username/public_html/

Fix or replace any HTTP references. Browsers will block mixed content by default in future versions.

12. Update mail client SSL settings if hosting email on the same server

If cPanel is also your mail server, clients connect to IMAP/SMTP over TLS. Installing a new certificate for the webmail domain doesn't automatically update the mail service certificates.

In WHM, go to Service Configuration → Manage Service SSL Certificates. Assign your new certificate to:

  • cPanel & WHM (for webmail and control panel access)
  • Exim (outbound SMTP)
  • Dovecot (IMAP/POP3)
  • FTP (if you use FTPS)

Restart each service after making changes. Tell users to update their saved certificates in Outlook, Thunderbird, or mobile mail apps—otherwise they'll see trust warnings on the next connection.

What happens if a step fails?

Most issues fall into three buckets: wrong files, incomplete chain, or stale cache.

Wrong files: re-download from your CA or regenerate the CSR if you lost the private key. You cannot recover a lost private key—you'll need to reissue the certificate.

Incomplete chain: concatenate the intermediate certificates in the correct order (your cert, then intermediate, then root if required). Some CAs provide a bundled file; others make you assemble it.

Stale cache: restart Apache, clear your browser cache, and flush Cloudflare or your CDN cache if applicable. SSL changes don't propagate instantly through all layers.

If external validation still fails after fixing the server side, check your firewall rules. Port 443 must be open and the correct certificate must be bound to the IP address. On servers with multiple IPs, SNI must be configured properly or you'll serve the wrong certificate to some clients.

FAQ

Do I need to restart Apache after installing an SSL certificate in cPanel?
cPanel usually restarts it automatically, but if you edited virtual host files manually, run systemctl restart httpd to be sure.

Can I use the same certificate on multiple cPanel servers?
Yes, as long as the certificate's SANs cover all the domains you're serving. Copy the CRT, KEY, and CA bundle to each server and install them individually.

What's the difference between a certificate bundle and a chain file?
They're the same thing—different CAs use different names. Both refer to the intermediate certificates that link your certificate to a trusted root.

Will AutoSSL overwrite my commercial certificate?
No. AutoSSL skips domains that already have a manually installed certificate. If you want AutoSSL to take over, delete the commercial cert first.

How do I test SSL without changing DNS?
Edit your local /etc/hosts file (or C:\Windows\System32\drivers\etc\hosts on Windows) to point the domain to your server's IP. Then visit https://example.com in your browser.

Install it right the first time

SSL rollbacks waste time and scare users. Walk through this checklist before you announce the switch and you'll catch the certificate mismatches, missing chains, and redirect loops that cause panic.

Verify the files, test the handshake, and check both web and mail services. It takes fifteen minutes and saves you from late-night firefighting.