SSL Error After cPanel WHM Server Reinstall: The Root Cause Your Admin Missed

Last Updated on 2 days ago by Sachin G

A client messaged late on a Monday night. Two live e-commerce websites. Payments broken for a portion of their customers. This was a classic SSL error after cPanel WHM server reinstall — but only showing for some users, not all. Their server admin had already looked at it. Their in-house DevOps team had looked at it.

After doing a deeper investigation on the SSL certificates, Cloudflare configuration, DNS records, and server setup, I was not able to find any clear misconfiguration or consistently reproducible issue from the server side. Because the problem appears randomly and cannot currently be reproduced reliably, I do not want to make changes blindly.

In other words, I gave up.

Within a few hours of investigation, the root cause was isolated — a missing DNS A record, an incomplete AutoSSL certificate, and a grey-cloud Cloudflare DNS record left unproxied after a server reinstall. None of it is exotic. All of it is completely fixable. But only if you know where to look. This article documents exactly how I found it, what I fixed, and what you need to check every single time after a cPanel/WHM server reinstall.

This article documents exactly how I found it, what I fixed, and what you need to check every single time after a cPanel/WHM server reinstall.

What Was Actually Happening Under the Hood

The client ran two Laravel + Livewire applications: client-site1.com and client-site2.com. Both sites used a shared payment referral subdomain — payments.example.com — as an approved referral domain registered with PayPal and Razorpay. When a customer checked out,the browser made a request to that subdomain as part of the payment handshake.
Specifically, here is the problem in plain terms.
After their WHM/cPanel server was reinstalled following a hosting provider security incident, the SSL certificate for payments.example.com was not cleanly reinstalled. Specifically, AutoSSL — WHM’s built-in Let’s Encrypt certificate manager — attempted to issue a certificate for the subdomain but could not complete validation for www.payments.example.com because that subdomain had no DNS A record pointing anywhere. No A record meant Let’s Encrypt could not perform the HTTP Domain Control Validation (DCV) check. No DCV meant no complete certificate. The AutoSSL log showed it clearly:

TLS Status: Incomplete WARN Local HTTP DCV error (www.payments.example.com): “www.payments.example.com” does not resolve to any IP addresses on the internet

At the same time, the payment’s DNS record in Cloudflare was set to DNS Only (grey cloud) — meaning Cloudflare was not proxying traffic to that subdomain at all. Every visitor request to payments.example.com went directly to the origin server, bypassing Cloudflare’s SSL edge entirely. Users who had previously loaded the site were being served cached responses through Cloudflare’s edge network — those users were fine. Users whose ISPs resolved directly to the origin IP, or whose cache had expired, hit the server with an incomplete SSL certificate and received an error. That is the complete explanation for why it was intermittent. Not random. Not mysterious. Entirely predictable once you understand the architecture.

Why Standard Advice Fails for SSL Error After cPanel WHM Server Reinstall

Every SSL error after cPanel WHM server reinstall looks the same on the surface — but the cause is almost never where you expect it. Search for SSL errors and Cloudflare, and the first twenty results will tell you the same things: check your SSL mode (Full vs Flexible), check for mixed content, check whether your cert is expired, and maybe flush your DNS cache. Every one of those is a valid starting point. None of them would have found this.

Here is why this scenario breaks the standard checklist.

WHM showed the certificate as valid. The main domain cert was present and valid. If you ran openssl s_client -connect client-site1.com:443 it would return clean. If you checked WHM’s SSL/TLS management page it showed a certificate in place. Nothing in the standard view tells you that a subdomain’s AutoSSL run is in a TLS Incomplete state — you have to specifically open the AutoSSL log and look at per-domain results.
The error was not reproducible from the client side. Because the client and their team were always being served through Cloudflare’s cache or through a proxied path, they never saw the error themselves. This is what made it look random. Intermittent SSL errors after cPanel WHM server reinstall are almost always an origin-direct vs Cloudflare-cached access pattern problem
— not a random TLS negotiation issue.

The Cloudflare DNS proxy status is not part of any standard SSL check. Furthermore, SSL Labs, browser dev tools, and WHM all operate at the certificate layer. None of them tell you whether a specific DNS record is grey-cloud or orange-cloud. You have to open Cloudflare’s DNS panel and look at each record individually.

The browser console errors looked like a code problem. The client shared screenshots showing Uncaught SyntaxError: Unexpected token ‘<‘ and $ is not defined — classic JavaScript errors. A developer looking at those would immediately start checking the application code, Livewire versions, or npm build output. These were not code errors. They were cascade failures: the browser was trying to load a JavaScript file from a URL that was returning an HTML error page because of the SSL failure. Fix the SSL, and the JS errors disappear automatically.

Step-by-Step Fix

These are the exact steps I guided through, in order. Every step has a purpose. Do not skip the verification steps — they are what prevent you from spending another two hours wondering why the fix did not work.

Step 1 — Add the Missing DNS A Record in Cloudflare

The immediate blocker was that www.payments.example.com had no DNS A record. AutoSSL
needed it to complete HTTP DCV.

Go to Cloudflare → your domain → DNS → Add record.

Type: A
Name: www.payments
IPv4: [your server IP ]
Proxy: DNS Only (grey cloud)
TTL: Auto

Note on the Name field: Cloudflare only accepts the subdomain portion in the Name field — not the full FQDN. Enter www.payments and Cloudflare appends .example.com
automatically. Entering the full hostname will either fail or cause a duplicate record.

Allow 1–2 minutes for DNS to propagate before running AutoSSL.

Step 2 — Run AutoSSL in WHM and Verify TLS Complete

WHM → SSL/TLS → Manage AutoSSL → Run AutoSSL For All Users

After it runs, click the log and verify:

TLS Status: Complete
Certificate expiry: [valid future date]

If you still see TLS: Incomplete, check the log for specific DCV errors. The log will tell you exactly which subdomain failed and why.

Warning: AutoSSL runs asynchronously. Do not assume it has completed just because the
button became clickable again. Wait for the log to show a completion timestamp before
moving to the next step.

Step 3 — Enable Cloudflare Proxy on the Payments Subdomain

Once the origin SSL certificate is valid, switch the payments A record from DNS Only to Proxied

Cloudflare DNS → find the 'payments' A record → Edit
Change: DNS Only (grey cloud)
To: Proxied (orange cloud)
Save

This means all traffic to payments.example.com now routes through Cloudflare’s edge, which handles SSL for visitors regardless of what the origin cert state is. This is your safety net.

Imagessssss

Important: After enabling the Cloudflare proxy, temporarily set your Cloudflare SSL/TLS mode to Full (not Full Strict). Full Strict requires a validated cert on the origin — ifAutoSSL has not fully propagated yet, Strict will break the connection. Switch back to Full (Strict) after you have verified the origin cert is clean via SSL Labs.

Step 4 — Set Cloudflare SSL Mode Correctly

Cloudflare → SSL/TLS → Overview
Set mode to: Full (temporarily)
After SSL Labs confirms A grade on origin:
Set mode to: Full (Strict)

Full (Strict) is the only mode that provides end-to-end encrypted validation. Never run
production sites on Flexible — it sends traffic from Cloudflare to your origin over plain HTTP.

Step 5 — Enable Automatic HTTPS Rewrites

Cloudflare → SSL/TLS → Edge Certificates → Automatic HTTPS Rewrites: ON

Do this for all your domains. This prevents mixed content issues where HTTP asset URLs are embedded in HTTPS pages — a common post-reinstall problem in Laravel and WordPress

Step 6 — Fix Laravel .env on Both Applications

Open the .env file for each Laravel application via WHM Terminal or SSH:

nano /home/clientuser1/public_html/.env

Verify and correct these values:

env

# Must match exactly how users access the site
APP_URL=https://www.client-site1.com

# Never true on production
APP_DEBUG=false

# Must be unique per application — never share between apps
APP_KEY=base64:[unique key here]

bash
nano /home/clientuser2/public_html/.env

env
APP_URL=https://client-site2.com
APP_DEBUG=false

If both applications share the same APP_KEY (this happens during server reinstalls where .env files are copied or restored from backup), regenerate the key on one of them:

cd /home/clientuser/public_html
php artisan key:generate

Warning: php artisan key:generate invalidates all existing encrypted data including user sessions. Every logged-in user will be logged out. Run this during low traffic hours and inform the client beforehand.

Step 7 — Clear All Laravel Caches on Both Sites

php artisan config:clear
php artisan cache:clear
php artisan view:clear
php artisan route:clear

Or combined:

php artisan optimize:clear

Alt text: Screenshot by TechTransit.org: Running php artisan optimize:clear in terminal
Caption: TechTransit.org | Clearing all Laravel caches after .env changes

Run this on both applications. Config changes in .env do not take effect until the config cache is cleared.

Step 8 — Verify with SSL Labs

Do not trust the browser. Do not trust “it looks fine to me.” Use an independent external validator:

https://www.ssllabs.com/ssltest/analyze.html?d=payments.example.com

You are looking for:

• Grade: A orA+
• No certificate chain errors
• No protocol warnings

If it returns a B or lower, check the specific warnings — SSL Labs tells you exactly what is wrong.

After all fixes are applied, force Cloudflare to serve fresh content:

Cloudflare → Caching → Configuration → Purge Everything

Do this for all affected domains. Old cached responses — including error responses — need to be cleared so all users get the fixed version immediately.

The Gotchas

These are the three things that will trip you up with this exact class of problem. Not from
documentation — from production.

1. WHM showing a valid certificate does not mean all subdomains are covered.
   This is the single biggest source of confusion in post-reinstall SSL debugging. The main domain
   cert can be perfectly valid and show green in every tool you check — while a subdomain is sitting
   in TLS Incomplete status and serving a broken handshake to direct-access users. The only place
   this shows up is inside WHM → AutoSSL → the detailed log for that specific cPanel account. Most
   admins never open the per-domain AutoSSL log. They look at the main SSL/TLS page, see a cert,
   and stop there. Always go deeper.
2. Cloudflare proxy status is invisible to every SSL diagnostic tool.
   SSL Labs, testssl.sh, OpenSSL, browser DevTools — none of them tell you whether a DNS record
   is proxied or DNS-only in Cloudflare. They test what they can reach. If a record is DNS-only, they
   test the origin directly. If the origin cert is broken, they report an error. If the origin cert is fine but
   the Cloudflare proxy is misconfigured, they report it as fine.Therefore, You need to physically open
   Cloudflare DNS and look at every single A and CNAME record for the affected domains after a
   server reinstall. Grey cloud on a payment subdomain is a silent killer.
3. The www.payments subdomain A record in Cloudflare — the Name field is not a full
   hostname.
   When adding a DNS record for www.payments.example.com in Cloudflare, you enter
   www.payments in the Name field — not the full domain. Cloudflare appends the root domain
   automatically. If you try to type www.payments.example.com you will hit a character-limit error
   or Cloudflare will reject it. This is a Cloudflare UI behaviour that is not obvious the first time you
   encounter a multi-level subdomain. Junior admins often get stuck here, assume the record
   cannot be created, and give up.

Best Practices and Prevention

A server reinstall is not complete until you have verified all of the following. Build this into a Checklist and run it every time.

Immediately after WHM reinstall:

Run AutoSSL and verify TLS Status: Complete for every domain and subdomain — not just the main domain:

WHM → SSL/TLS → Manage AutoSSL → Run for all users
Review log → confirm no TLS Incomplete entries

Audit every DNS record in Cloudflare for grey vs orange cloud status. Payment subdomains, API subdomains, and any subdomain involved in active user requests should be proxied unless there is a specific technical reason not to.
Check every Laravel .env file: APP_DEBUG=false , APP_URL uses https://, and eachThe
application has its own unique APP_KEY.

Ongoing monitoring:

Set up SSL expiry monitoring on all subdomains, not just main domains. UptimeRobot Free tier supports SSL monitoring and sends email alerts when a cert is within 30 days of expiry. This catches AutoSSL renewal failures before they become customer-facing problems. Enable Cloudflare SSL expiry notifications under SSL/TLS → Edge Certificates → Certificate Transparency Monitoring. Set up uptime monitoring on your payment subdomains specifically. A payment subdomain going down is different from a marketing page going down — it is a direct revenue impact and needs to alert within minutes, not hours

Hardening:

• Always use Cloudflare SSL mode: Full (Strict) in production. Never Flexible.
• Enable Automatic HTTPS Rewrites on all Cloudflare domains.
• Install a Cloudflare Origin Certificate (valid for 15 years) on the origin server alongside
• Let’s Encrypt — gives you a fallback ifAutoSSL renewal fails.
• Never share APP_KEY across multiple Laravel applications on the same server.
• Set APP_DEBUG=false on all production .env files — a debug-enabled Laravel app
• exposes full stack traces including file paths, database credentials, and environment
• variables to anyone who can trigger an error

Conclusion

The most dangerous production incidents are not the ones that crash everything — those are obvious. The dangerous ones are the ones that appear random, affect only some users, and leave even experienced engineers saying they cannot reproduce the issue. SSL errors after cPanel WHM server reinstall fall squarely in this category.

What separated this diagnosis from the others was not any single command or tool. It was understood that Cloudflare caching creates a two-tier access pattern — proxied users and direct-origin users — and that the intermittent symptom was not random but entirely determined by which tier a given user hit. Once that mental model was in place, every piece of evidence pointed to the same place: an incomplete AutoSSL cert on a subdomain that was sitting exposed without Cloudflare proxy protection.

As a result, the fix required touching four separate systems — WHM AutoSSL, Cloudflare DNS, Cloudflare SSL settings, and the Laravel application config. No single-system checklist was ever going to find it. If you manage production servers on WHM/cPanel behind Cloudflare, build a post-reinstall verification checklist and run it before you declare a server restored. The fifteen minutes it takes to verify AutoSSL status for every subdomain is worth more than the hours you will spend debugging the intermittent SSL error that follows when you skip it

Need this fixed on your server? I provide emergency SSL, DNS, and Cloudflare troubleshooting as a fixed-price service on Fiverr:👉techtransit — Emergency Linux Server, SSL, DNS & Hosting Error Fix Or contact me for ongoing server management and infrastructure support

Sachin G

I’m Sachin Gupta — a freelance IT support specialist and founder of techtransit.org. I’m certified in Linux, Ansible, OpenShift (Red Hat), cPanel, and ITIL, with over 15 years of hands-on experience. I create beginner-friendly Linux tutorials, help with Ansible automation, and offer IT support on platforms like Upwork, Freelancer, and PeoplePerHour. Follow Tech Transit for practical tips, hosting guides, and real-world Linux expertise!

www.techtransit.org