Disable Old TLS Versions & Weak Ciphers in WHM

If a PCI compliance scanner or an SSL Labs test just came back with "TLS 1.0 supported," "weak cipher suite detected," or "vulnerable to POODLE/BEAST," you're not alone — it's one of the most common flags on VPS and dedicated servers running wordpress-missing-a-temporary-folder-upload-error" class="auto-link">cPanel/WHM, because the default Apache and Exim configs are built for broad compatibility, not for a clean scan report. The good news is the fix is a config change, not a rebuild. Here's how to do it without locking out legitimate visitors or your own mail clients.

Symptom: What the Scan Actually Flags

Read the scan report carefully before touching anything — it usually names one of these:

• TLS 1.0 / TLS 1.1 enabled — both were formally deprecated by the major browsers and PCI-DSS 3.2.1 in 2021, but WHM still enables them on older installs for compatibility with ancient clients.
• Weak or export-grade ciphers — RC4, 3DES, or anything under 128-bit, often left in the cipher list from years-old defaults.
• SSLv2 / SSLv3 supported — rare now, but still shows up on servers that haven't had WHM's SSL/TLS templates touched since setup.
• No forward secrecy — the cipher order allows non-ECDHE key exchange, so a scanner marks it down even though the certificate itself is fine.

None of this is about your SSL certificate being wrong — AutoSSL or a paid cert can be perfectly valid while the underlying protocol negotiation is still what fails the scan.

Cause: cPanel Defaults to Compatibility, Not Strictness

WHM's Apache TLS settings are deliberately conservative out of the box, because disabling old protocols can break connections from very old devices, some legacy payment terminals, and internal tools that still speak TLS 1.0. cPanel won't change this for you automatically — it's a decision the server owner has to make, since it's the one setting with a real (if small) compatibility trade-off.

Fix: Tighten TLS in WHM

This applies at the WHM/root level, so you'll need root access — a VPS or dedicated server, not a shared hosting account.

Step 1: Update the Apache TLS protocol list

In WHM, go to Service Configuration » Apache Configuration » Global Configuration. Find the SSLProtocol directive and set it to:

SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1

This leaves TLS 1.2 and TLS 1.3 (if your Apache/OpenSSL build supports it) as the only options a browser can negotiate.

Step 2: Trim the cipher suite

In the same screen, update SSLCipherSuite to drop RC4, 3DES, and non-forward-secrecy ciphers:

SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305

Set SSLHonorCipherOrder to On so the server — not the client — picks the strongest match first, then rebuild and restart Apache from WHM (or /scripts/rebuildhttpdconf && service httpd restart over SSH).

Step 3: Do the same for Exim and Dovecot

A scan often flags mail ports too. In WHM's Exim Configuration Manager » Advanced Editor, and in /etc/dovecot/conf.d/10-ssl.conf, apply the equivalent ssl_min_protocol setting so port 465/587/993/995 match the same TLS floor as the web server. Skipping this is the most common reason a "fixed" server still fails a re-scan.

Step 4: If you're behind Cloudflare or a reverse proxy

The TLS negotiation the scanner sees is whichever layer terminates SSL first. If Cloudflare proxies the domain, set the minimum TLS version under SSL/TLS » Edge Certificates » Minimum TLS Version there too — hardening only the origin server won't change what a scanner sees on the edge.

Quick Reference

Verify the Fix

Don't take WHM's word for it — confirm from outside the server. Run an SSL Labs test against the domain, or check quickly from the command line:

openssl s_client -connect yourdomain.com:443 -tls1_1

A handshake failure here is what you want — it means TLS 1.1 is actually rejected, not just hidden from one client. Re-run the PCI scan once the SSL Labs grade comes back clean; most scanners re-check within a day of the config change.

Prevention: Keep It From Drifting Back

• WHM/cPanel updates occasionally reset SSLProtocol and SSLCipherSuite to package defaults — check these two lines after any major cPanel version bump.
• If you manage multiple servers, keep the Apache TLS block in a WHM template or a config-management snippet so a rebuild doesn't silently revert it.
• Re-run an SSL Labs check quarterly, or right after installing a new mail client integration — that's usually when someone reports "it broke" and you find out a device was still relying on TLS 1.0.

Frequently Asked Questions

Will disabling TLS 1.0/1.1 break anything for normal visitors?

Almost never. Every browser released since 2020 supports TLS 1.2 by default. The devices that break are old point-of-sale terminals, some IoT hardware, and very old Android/iOS versions — worth checking your traffic logs for before rolling this out on a high-traffic checkout page.

Do I need to touch anything if my site sits fully behind Cloudflare?

Yes, both ends. Cloudflare's edge TLS setting controls what the scanner sees when it hits your domain; your origin's Apache setting controls what happens if someone connects directly to the server's IP, which a thorough PCI scan will also probe.

My scan still shows TLS 1.1 after I changed SSLProtocol — why?

Usually because Apache wasn't rebuilt/restarted after the WHM change, or because the scan hit a different vhost (an addon domain or a mail subdomain) that has its own SSL config block overriding the global one.

Does this affect AutoSSL or my existing certificates?

No — certificates and protocol/cipher settings are independent. AutoSSL keeps issuing and renewing certs exactly as before; you're only changing which protocol versions and cipher suites are allowed to use them.

Is TLS 1.3 worth enabling too?

Yes, if your OpenSSL and Apache/httpd versions support it (OpenSSL 1.1.1+). It's faster to negotiate and has no known weaknesses, so most WHM templates now include it alongside TLS 1.2 rather than as a replacement.