cPanel/WHM 'Not Secure' at Port 2083? Fix the Panel SSL

You log into WHM to check on a client's site and Chrome throws up "Your connection is not private." Your website's padlock is green and fine - this warning is coming from cPanel or WHM itself, on port 2083 or 2087. It's a different certificate than the one securing the sites you host, and it breaks for different reasons than a normal "Not Secure" website warning. Here's what's actually going on and how to fix it for good.

Symptom: what you're actually seeing

This shows up in a few slightly different ways depending on your browser and setup:

• Chrome or Firefox blocks https://yourserver.com:2083 with NET::ERR_CERT_COMMON_NAME_INVALID or a plain "Your connection is not private" screen
• Clicking "Certificate details" shows a name you don't recognize - something like *.yourhostingprovider.com, cprapid.com, or a self-signed cert labeled "cPanel Default Certificate"
• WHM at :2087 and Webmail at :2096 throw the same warning, even though https://yourdomain.com loads with a perfectly valid padlock
• The warning appears when you type the server's IP address in the URL bar, but goes away when you use the hostname - or vice versa

The key thing to notice: your website's SSL and your panel's SSL are two completely separate certificates, issued and renewed independently. Fixing one does nothing for the other.

Cause: the panel has its own certificate, separate from every site you host

cPanel and WHM run on a background service called cpsrvd, which serves the cPanel interface (2083), WHM (2087), Webmail (2096), and a few other panel ports. That service needs its own SSL certificate, matching its own name - and that name is the server's hostname, not any of the domains parked or hosted under it. When people say "cPanel's SSL is broken," it's almost always one of four things.

1. You're browsing by IP address

A certificate is issued for a name (a hostname or domain), never for a bare IP address. If you access the panel at https://185.xx.xx.xx:2083, no certificate on earth will match, and the browser will always flag it - even if everything else is configured correctly. This one isn't a bug; it's how TLS works.

2. The server hostname isn't a real, DNS-resolvable domain

Most VPS images ship with a placeholder hostname like localhost.localdomain or an auto-generated string your provider assigned at spin-up, such as vmi482913.contabo.host. AutoSSL can only issue a certificate for the hostname if that hostname is a domain you actually control, with an A record pointing at the server. If it's a placeholder with no matching DNS record, AutoSSL silently fails and cPanel falls back to a self-signed certificate.

3. AutoSSL never got asked to cover the panel service

AutoSSL runs per cPanel account by default, securing the domains hosted in each account. The hostname itself - the name the panel uses for its own login screen - is a separate target that WHM handles under Manage Service SSL Certificates. If that was never pointed at an AutoSSL-issued cert, or was skipped during initial server setup, the panel keeps serving whatever self-signed certificate it shipped with.

4. An old or wrong certificate is still selected as the "Service Certificate"

Even when a valid certificate for the hostname exists on the server, WHM won't use it automatically for cPanel/WHM/Webmail unless it's explicitly selected as the service certificate. It's easy to renew a cert and forget this last step, so the panel keeps handing out the expired one it was using before.

Fix: get a real certificate assigned to the panel

1. Confirm the hostname and its DNS record. Run:

   hostname -f
   dig +short yourhostname.example.com A

   The output of dig should match your server's actual IP. If it returns nothing, fix the A record before doing anything else - AutoSSL can't validate a hostname that doesn't resolve.
2. Verify the hostname in WHM. Go to WHM Home > Server Configuration > Basic WebHost Manager Setup and check the Hostname field matches step 1 exactly.
3. Run AutoSSL for the hostname. Go to WHM Home > SSL/TLS > Manage AutoSSL and click Run AutoSSL For All Users. If the hostname is a domain owned by the root/WHM account rather than a cPanel user, this step may not touch it - see the note below.
4. Point the panel at that certificate. Go to WHM Home > Service Configuration > Manage Service SSL Certificates, select cPanel/WHM/Webmail, click Browse Certificates, and choose the certificate issued for the hostname. Install it.
5. Restart the panel service so it picks up the new certificate immediately instead of waiting for its own refresh cycle:

   /usr/local/cpanel/scripts/restartsrv_cpsrvd

6. Always access the panel by hostname, not IP, going forward - bookmark https://yourhostname.example.com:2083 instead of the raw IP address.

If AutoSSL still won't cover the hostname

The hostname needs to be recognized as a domain WHM can validate - which usually means it should NOT also be actively hosted as a website under a cPanel account (that's a common conflict: using yourdomain.com as both the server hostname and a hosted site). Pick a dedicated FQDN for the server that isn't one of your live sites, like server1.yourdomain.com, point an A record at it, and re-run the steps above.

If you're on Getwebup shared hosting or a managed VPS

You won't have WHM root access on shared plans, so you can't run these steps yourself. Open a support ticket and ask Getwebup to confirm AutoSSL coverage for the server's own hostname - it's a five-minute check on our side and doesn't touch your website's certificate at all.

Quick reference

Prevention

Set a real, dedicated FQDN as the server hostname at provisioning time, before you host a single site on the box - it's far more annoying to change later, since mail delivery, license activation, and the panel's SSL all key off it. Once AutoSSL is covering the hostname correctly, it renews automatically every 90 days along with your other certificates, so this shouldn't come up again unless the hostname itself changes or DNS for it lapses. If you do change the server hostname down the line, treat it as a two-step job: update DNS first, confirm it resolves, then update the hostname in WHM - not the other way around.