cPanel Hostname SSL: Let’s Encrypt AutoSSL Fix in WHM

Modern cPanel builds default to Sectigo as the AutoSSL provider, and on version 136 and later the certificates it issues are short-lived, roughly 200 days, with automatic reissue. Many administrators still prefer Let’s Encrypt for its rate-limit transparency and its independence from the cPanel licence, and both providers can be enabled in a few clicks. The second half of the job is the service certificate for the hostname itself: the one that browsers see on port 2087, that mail clients see on 993 and 465, and that FTP clients see on 21. When that one is expired or self-signed, every mail client on the server complains.

Short answer: Run /usr/local/cpanel/scripts/install_lets_encrypt_autossl_provider, then in WHM » SSL/TLS » Manage AutoSSL choose the Let’s Encrypt provider, accept its terms and save. Trigger a run for all accounts from the Manage Users tab or with /usr/local/cpanel/bin/autossl_check --all. For the hostname, run /usr/local/cpanel/bin/checkallsslcerts --verbose, which issues a certificate for the server’s hostname and installs it on cpsrvd, Dovecot, Exim and FTP, then confirm at https://hostname:2087.

Enable the Let’s Encrypt provider

The provider module is not present on a fresh install. Install it from the shell, then switch providers in WHM:

/usr/local/cpanel/scripts/install_lets_encrypt_autossl_provider
whmapi1 set_autossl_provider provider=LetsEncrypt
whmapi1 get_autossl_providers

The WHM path is SSL/TLS » Manage AutoSSL, Providers tab, where you tick the terms of service checkbox before saving. On version 136 and later, the same page lives inside the unified SSL/TLS interface but the option names are unchanged. Under the Options tab decide whether AutoSSL may replace certificates that were installed manually and whether it should notify users on failures; most hosting providers leave replacement off and notifications on. The Manage Users tab controls which accounts and feature lists are eligible.

Run AutoSSL and read the log

Force an immediate run rather than waiting for the nightly cron:

/usr/local/cpanel/bin/autossl_check --all
/usr/local/cpanel/bin/autossl_check --user=example

The Logs tab in Manage AutoSSL shows each domain and the reason for any exclusion. The two failures that account for most tickets are domain control validation problems. DNS validation fails when a domain’s nameservers point elsewhere and the A record does not resolve to this server; the fix is to update DNS or exclude the domain from AutoSSL in the user’s SSL/TLS Status page so it stops blocking the certificate for the rest of the account.

HTTP validation fails when port 80 is redirected wholesale to HTTPS or blocked by a .htaccess rule; cPanel normally injects an exception for /.well-known/, but custom rewrites written above it can still break it. A proxy such as Cloudflare in front of the domain also needs the DCV path to reach the origin, covered in the CAA and CDN DCV guide.

Fix the hostname certificate

The hostname certificate is separate from account certificates and is managed by checkallsslcerts. It runs daily from cron, but you can invoke it directly after fixing DNS:

hostname -f
dig +short $(hostname -f)
/usr/local/cpanel/bin/checkallsslcerts --verbose

The hostname must be a fully qualified name that resolves to an address on this server, and port 80 on that address must be reachable, because the certificate is requested with HTTP validation regardless of which AutoSSL provider is selected. On current builds cPanel obtains it from Sectigo. If the hostname does not resolve, set a proper A record first or change the hostname in WHM » Networking Setup » Change Hostname and rerun. Once issued, the certificate is installed automatically across the services; you can review or replace it at WHM » Service Configuration » Manage Service SSL Certificates, which lists cPanel/WHM/Webmail/Web Disk, Dovecot, Exim and FTP with each certificate’s expiry.

Verify

Check each service from outside:

openssl s_client -connect mail.example.com:993 -servername mail.example.com </dev/null 2>/dev/null | openssl x509 -noout -issuer -dates
openssl s_client -connect server.example.com:2087 </dev/null 2>/dev/null | openssl x509 -noout -subject -dates

The issuer should be a public CA, not the cPanel default, and the dates current. In a browser, https://server.example.com:2087 should show no warning. The SSL expiry check script can monitor these ports continuously.

Pitfalls

The most frequent mistake is expecting the AutoSSL provider selection to affect the hostname certificate; it does not, and complaints that Let’s Encrypt was chosen but Sectigo appears on port 2087 are working as designed. Another is a mail client configured for the customer’s own domain rather than the server hostname, which produces a name mismatch unless the account’s AutoSSL certificate includes the mail. subdomain; recent cPanel versions do include it, but check the SAN list. Finally, Let’s Encrypt applies rate limits per registered domain, so a reseller with fifty subdomains of one parent domain can hit the weekly cap; the log names the limit explicitly.

CPanel hostname SSL at a glance

Official documentation: Let’s Encrypt documentation, cPanel & WHM documentation, Linux man pages.

Related guides: Fix WordPress “cURL error 28: Failed to connect” caused by Imunify360 or CSF · CVE-2026-65638, 65639 and 67402 explained: patching the CSF Messenger and URLGET remote-code flaws · Whitelist IPs and countries in Imunify360 from the CLI.

Frequently asked questions