DEV Community: Daanial Farrukh

Cloudflare Free Plan Security — The Exact Settings I Run on My Own Site

Daanial Farrukh — Mon, 19 Oct 2026 17:15:39 +0000

A field note from my own WordPress site on Cloudflare’s free plan — what I switched on, what I left off on purpose, and the curl checks that prove each setting is really working.

I spend a lot of time in customer rooms asking one question about Cloudflare: “Which settings are actually on?”

Most of the time the answer is a shrug and a logo. “We’re behind Cloudflare.”

So I owe the same honesty about my own site.

This blog runs WordPress on shared hosting, behind Cloudflare, on the Free plan. No Pro, no Business, no add-ons. In July a WPScan report on my own site pushed me to do the full pass I normally do for customers.

I expected the free plan to run out quickly. It didn’t. It ran out in exactly two places — and I’ll show you both.

Everything below is a real screenshot from my own dashboard, taken today.

The Trap — “We’re Behind Cloudflare” Is Not a Setting

That’s the trap. Turning the orange cloud on gives you a proxy, a free certificate and DDoS protection at the edge. It does not give you a strict TLS chain, a WAF policy, security headers or any rule that knows what WordPress is.

Those are switches. Somebody has to flip them, and somebody has to prove they work.

Being behind Cloudflare is a starting point, not a security posture.

What the Free Plan Actually Gives You

Here’s the flow every request takes:

Visitor → Cloudflare edge (TLS, WAF, rate limit, headers) → Origin web server → WordPress

On the free plan, the parts you control at the edge are:

SSL/TLS — the encryption mode between Cloudflare and your origin, minimum TLS version, HSTS and HTTPS redirects.
Security rules — up to 5 custom WAF rules and 1 rate-limiting rule, plus Cloudflare’s managed free ruleset and DDoS protection, which are on by default.
Transform rules — add security headers to every response and strip the headers that leak your stack.

Five custom rules sounds tiny. It’s enough — if every rule earns its slot.

Why the Usual Check Misses It

The usual check is opening the site in a browser and seeing the padlock. The padlock only proves the visitor-to-Cloudflare leg. It says nothing about the leg from Cloudflare to your server, nothing about whether /xmlrpc.php is reachable, and nothing about which headers leave your origin.

Here’s the part that trips people up: Cloudflare will happily serve a green padlock in Flexible mode while the traffic to your origin is plain HTTP. The dashboard looks healthy. The chain is not.

So every step below ends with a command, not a screenshot. The screenshot shows intent. The command shows the truth.

How I Set It Up — Step by Step

Step 1: SSL/TLS mode — Full (Strict), nothing less

Cloudflare → your domain → SSL/TLS → Overview → Configure → Full (strict).

The SSL/TLS overview on my free-plan zone: current encryption mode Full (strict), browser to Cloudflare to origin, both legs encrypted.

Full (Strict) means Cloudflare encrypts the leg to your origin and checks that the origin certificate is valid. If your host has no valid certificate, a free Cloudflare Origin Certificate is enough — SSL/TLS → Origin Server → Create Certificate. My zone has one for the domain and its wildcard, valid until 2041.

Mine was already on Full (Strict). That was the one thing I didn’t have to fix.

Plain takeaway: if your mode says Flexible, fix that before you touch anything else on this page.

Step 2: HTTPS everywhere, TLS 1.2 minimum, HSTS without preload

SSL/TLS → Edge Certificates:

Always Use HTTPS — on.
Minimum TLS Version — TLS 1.2. Mine was still on TLS 1.0, the old default. That was a real finding.
TLS 1.3 — on.
HSTS — on, max-age 6 months, include subdomains on, no-sniff on, preload off.

Edge Certificates: HSTS on with a 6-month max-age and subdomains included, preload off, and the minimum TLS version set to 1.2.

Preload is off on purpose. Once a domain is on the browser preload list, getting it off takes months. I want HSTS to stay reversible while the site is still changing hosts and subdomains.

Plain takeaway: change minimum TLS to 1.2 today. Turn on HSTS only after every subdomain works on HTTPS.

Step 3: Five WAF custom rules — every slot earns its place

Security → Security rules → Custom rules → Create rule. The free plan gives you five. I used all five.

Security rules on the free plan: five of five custom rules in use, all set to Block.

Block XML-RPC. Path equals /xmlrpc.php. It is the classic pingback-DDoS and login-amplification door, and nothing on my site needs it.
Block info-disclosure files. readme.html, license.txt, wp-config.php, the install and setup scripts, anything with /.env or /.git/, and files ending in .sql, .bak or .log.
Block PHP inside uploads. Path starts with /wp-content/uploads/ and ends with .php. Uploads should only ever hold images and PDFs. A PHP file there is a webshell.
Block known scanners by user agent. wpscan, sqlmap, nikto, masscan, nuclei, wfuzz, dirbuster — matched on the lower-cased user agent.
Block an endpoint I never asked for. More on this one below — it was the most surprising finding of the whole pass.

The expression for rule 3, so you can copy it:

(starts_with(http.request.uri.path, "/wp-content/uploads/") and ends_with(http.request.uri.path, ".php"))

Rule 4 is the weakest of the five. Any serious attacker changes the user agent. It still removes the lazy automated noise from my logs for free, so it keeps its slot.

Step 4: The fifth rule — the MCP server a plugin shipped without asking

During the same pass I found a REST route on my own site at /wp-json/mcp/mcp-adapter-default-server. I had not installed it.

It turned out my SEO plugin, Rank Math, bundles the official WordPress MCP adapter library and registers it on update. It needs authentication — anonymous requests get a 401 — and it pairs with the Abilities API that now sits in WordPress core. But it can execute abilities, and it accepts Application Passwords, which bypass 2FA. There was no toggle in the plugin to turn it off.

I want to be fair here: nothing was compromised. My Application Passwords list was empty at the time, so nothing had ever been authorised to use it. It was simply surface I didn’t need.

So I closed it twice:

At Cloudflare: rule 5 blocks paths starting with /wp-json/mcp and any query string containing rest_route=/mcp.
At the origin: a small must-use plugin removes the mcp routes through WordPress’s rest_endpoints filter, so the namespace is gone from /wp-json/ even if someone reaches the server directly.

Check your /wp-json/ index for namespaces you don’t recognise. Plugins add surface on update, quietly.

Step 5: Rate limiting — the free plan’s honest limit

Security → Security rules → Rate limiting rules. One rule on the free plan. Mine protects the login form:

POST /wp-login.php — more than 3 requests in 10 seconds from the same IP → Block.

The single free-plan rate-limiting rule: POST requests to wp-login.php, action Block.

Here’s the honest part. On the free plan the counting period is locked to 10 seconds and the block lasts only 10 seconds. The API rejects anything longer as “not entitled”. A patient brute-force script that sends two guesses every ten seconds never trips it.

So I treat this rule as a speed bump, not a lock. The real login defence lives at the origin: a security plugin’s lockout after failed logins, and TOTP two-factor on the only admin account.

Plain takeaway: on the free plan, rate limiting slows a burst. It does not stop a brute-force. Plan for that.

Step 6: Security headers at the edge — add the good ones, strip the leaky ones

Rules → Transform Rules → Modify Response Header. One rule, applied to every response:

Adds X-Frame-Options, Referrer-Policy, Permissions-Policy and Cross-Origin-Opener-Policy.
Removes x-powered-by, platform and panel — headers my host added that advertised details of the hosting stack to anyone who asked.

Doing this at the edge means the headers are the same on cached pages and uncached pages, and I never have to edit server config on shared hosting.

Step 7: The switches I left off — on purpose

This is the section most hardening guides skip.

Bot Fight Mode is off on this zone, deliberately.

Bot Fight Mode — off. It challenges SEO crawlers like Ahrefs, Semrush and Moz, and uptime monitors too. This site exists to be found, so I chose targeted WAF rules over a blanket bot challenge.
AI crawlers — allowed. Being cited in AI answers is traffic I want. AI Labyrinth stays off for the same reason.
HSTS preload — off, as explained in Step 2.

Security level stays at Medium and Browser Integrity Check stays on. Those cost nothing in reach.

Maximum security is not every switch on. It is every switch decided.

Step 8: The origin — where the free plan stops

Cloudflare only protects traffic that goes through Cloudflare. If someone finds your origin IP, they can skip the edge completely.

Two honest notes from the field:

Authenticated Origin Pulls is off on my zone. It makes Cloudflare present a client certificate to your origin, so the origin can refuse anything that isn’t Cloudflare. The switch is free. The work is on the origin web server, which has to be configured to demand that certificate — and on shared hosting that is not my server to configure. So I compensate at the origin: the security plugin’s firewall runs in its extended mode, XML-RPC is disabled there too as a backup to the edge rule, and unused themes are deleted.

Never lock admin ports to Cloudflare’s IP ranges. On a customer’s cPanel server, I once locked myself out of WHM. The firewall allowed WHM only from my admin IP. I opened it through a hostname that was proxied by Cloudflare — and Cloudflare proxies the cPanel and WHM ports. The server saw a Cloudflare IP, not mine, and dropped the connection. SSH on port 22 still worked, which was the clue: Cloudflare’s normal proxy doesn’t carry it.

The fix was not to allow Cloudflare’s ranges. That would open WHM to anyone who routes through Cloudflare. The fix was to reach WHM on the origin IP directly, and keep the server’s own hostname grey-cloud (DNS only). Public sites stay orange. Only the admin path skips Cloudflare.

Verify It — Where Most Tutorials Stop

This step is where most tutorials stop and where mine starts. Replace example.com with your domain. Every command is read-only.

Blocked paths should return 403:

curl -s -o /dev/null -w "%{http_code}\n" https://example.com/xmlrpc.php

curl -s -o /dev/null -w "%{http_code}\n" https://example.com/wp-content/uploads/test.php

curl -s -o /dev/null -w "%{http_code}\n" https://example.com/wp-json/mcp/mcp-adapter-default-server

On my site all three return 403, and so do /readme.html and /?rest_route=/mcp. The home page returns 200. If a blocked path returns 200 or 404, the rule is not matching — check the expression, then wait 30 seconds and test again with a cache-busting query string like ?x=1, because rule changes take a moment to reach every edge.

A scanner user agent should be refused:

curl -s -o /dev/null -w "%{http_code}\n" -A "WPScan v3.8" https://example.com/

Expected: 403. The same URL with a normal browser user agent returns 200.

Old TLS should fail, current TLS should pass:

curl -s -o /dev/null -w "%{http_code}\n" --tlsv1.0 --tls-max 1.0 https://example.com/

Expected: no page at all — a handshake error, and a status of 000. Run it again with --tlsv1.2 --tls-max 1.2 and you should get 200. This error is not a bug. It is the verification.

Headers should be added and leaks removed:

curl -s -D - -o /dev/null https://example.com/

Look for Strict-Transport-Security: max-age=15552000; includeSubDomains, X-Frame-Options, Referrer-Policy, Permissions-Policy and Cross-Origin-Opener-Policy. And look for what is not there: no x-powered-by, no panel, no platform. Use a real GET like this one, not curl -I — a HEAD request can take a different path through your cache rules and fool you.

On Windows, if curl fails with a certificate revocation error before it ever reaches the site, add --ssl-no-revoke. That is a local Windows check, not a problem with your site.

The Free-Plan Checklist I Now Run

Encryption mode is Full (Strict). SSL/TLS → Overview.
Minimum TLS is 1.2 and Always Use HTTPS is on. The --tls-max 1.0 test fails.
HSTS is on, preload is a decision. Strict-Transport-Security is in the response headers.
All five custom rules are used, each with a reason. Every blocked path returns 403.
The rate-limit rule exists, and you know it is only a speed bump. Login lockout and 2FA live at the origin.
Headers are added and leaks are stripped at the edge. No x-powered-by in the response.
Every switch left off is written down with its reason. Bot Fight Mode, AI crawlers, preload.
The admin path does not go through Cloudflare, and Cloudflare’s ranges are never on an admin allow-list.

What I Tell Every Customer Now

The free plan is not the weak link. The undecided switch is.

So in every review I ask one question:

“Can you show me, with a command, that each Cloudflare rule you think you have is actually blocking something?”

If the answer is a list of 403s, they’re in good shape. If the answer is “it’s in the dashboard,” we’re not done yet.

I write about the questions I ask in real customer rooms — the ones that change architectures and surface the problems no one else noticed. If you found this useful, drop your email below and I’ll send the next one when it’s ready.

FAQs

Is the Cloudflare free plan enough to secure a WordPress site?

For a small site, it covers a lot: Full (Strict) TLS, HSTS, five custom WAF rules, one rate-limiting rule, managed rules and DDoS protection. It runs short on rate limiting, which is locked to a 10-second window, and it cannot protect an origin that attackers reach directly. Pair it with a login lockout and 2FA at the origin.

Which Cloudflare SSL mode should I use?

Full (Strict). It encrypts the connection from Cloudflare to your server and checks that the server’s certificate is valid. A free Cloudflare Origin Certificate on your server is enough to make it work. Flexible mode leaves that leg unencrypted while still showing visitors a padlock.

Why does the free plan’s rate limiting not stop brute-force attacks?

On the free plan the counting period and the block duration are both locked to 10 seconds. A slow script that stays under the threshold is never blocked, and a blocked one is free again after 10 seconds. Use it to slow bursts, and rely on an origin-side lockout and two-factor login for real protection.

Should I turn on Bot Fight Mode?

Only if being crawled is not important to you. Bot Fight Mode also challenges SEO crawlers and uptime monitors. If your site depends on search traffic, targeted WAF rules for the paths and tools you actually want to block are the better trade.

How do I check that my Cloudflare WAF rules are working?

Request a path the rule should block with curl and read the status code. A working block rule returns 403. If you see 200 or 404, the expression is not matching; wait about 30 seconds after any change and add a cache-busting query string before you test again.

Should I whitelist Cloudflare IP ranges for cPanel or WHM access?

No. That opens your admin ports to anyone who routes through Cloudflare. Reach admin panels on the origin IP directly, keep the server’s own hostname DNS-only (grey cloud), and allow only your admin IP in the firewall.

Download the PDF

Originally published at quabin.com.

The Outage That Wasn't a DDoS

Daanial Farrukh — Sun, 18 Oct 2026 19:42:10 +0000

A presales war story about a website that kept dying while the control panel stayed perfectly healthy — and the two numbers in the logs that nobody had compared.

The message came in the same way these messages always do:

“The site is down again. Webmail too. We think it’s a DDoS.”

Then, a minute later: “But WHM is working fine.”

I asked one question: “How many PHP processes is the site allowed to run?”

Silence. Then: “What does that have to do with a DDoS?”

Everything, as it turned out. The site was a busy public portal on a cPanel server. Twice in two days it had become unreachable for real users for twenty to thirty minutes, then recovered on its own. Webmail on the same box died with it. The control panel on port 2087 never blinked. The team had already restarted Apache, checked the firewall, and started drafting a request for DDoS protection.

That’s the trap. An outage with no attacker, no error and no crash looks exactly like an attack. It isn’t. It hides in plain sight, in two numbers that live in different files.

Why “WHM Works” Tells You Nothing

The first thing I corrected was the assumption that the server was healthy because the control panel loaded.

WHM is served by cpsrvd, a separate daemon. It does not pass through Apache at all. So on a cPanel box, WHM on port 2087 being fast while the website on port 443 is dead means precisely one thing: the problem is inside the web stack, and the server itself is fine. That is a useful clue, not a reassurance.

Webmail was the second clue. On this server, webmail is proxied through Apache. When Apache has no free worker, webmail dies along with the site. Two symptoms, one bottleneck.

Absence of Errors Is Not Health

The team’s strongest argument for “it must be an attack” was the error log. It was empty. Apache had not crashed, had not restarted, and had logged nothing during either incident.

tail -20 /usr/local/apache/logs/error_log

Nothing. And that is expected. Saturation is not an error. When every worker is busy, Apache does not fail — it waits. New connections queue. Users see a spinner, then a timeout. Nothing in that sequence is an error from Apache’s point of view, so nothing gets logged.

If you only look for errors, you will never find a capacity problem. You have to look at the traffic.

Step 1: Count Requests Per Minute

The access log for the domain is where the story lives. On cPanel the HTTPS traffic is in the -ssl_log file, not the plain one.

awk '{print $4}' /usr/local/apache/domlogs/example.com-ssl_log | cut -d: -f2,3 | sort | uniq -c | tail -30

That prints a request count for every minute of the day. The outage window stood out immediately: a flat line of roughly 700 requests a minute, every minute, for twenty minutes. Then it fell to 20 in a single minute, and the site came back.

Here is the detail that settled the argument about causation: real traffic reappeared in the same minute the flood stopped. Images, scripts, the homepage, the first webmail login — all of it returned at the moment the flood ended, not one minute earlier. Whatever that traffic was, it was locking users out.

Step 2: Find Out What the Traffic Was Asking For

grep '10:1[0-9]:' /usr/local/apache/domlogs/example.com-ssl_log | awk '{print $7}' | sort | uniq -c | sort -rn | head

Every one of the 7,000 requests in that window — 100 percent — hit the same page: the public listing page of the portal. And every URL was unique. They looked like this:

/page-listing?list=36?list=42?list=42?list=42?list=42

A valid URL can contain only one ?. Anything after the first one is the query string. These URLs had a second, a third, a tenth. They were malformed, and they were growing: each request was one ?list= longer than the previous one.

That pattern has only one explanation. A crawler was taking each category link on the page and appending it to the address it was already on, instead of replacing the query string. Every page it loaded minted new links, every new link was unique, and the crawl never ended.

I want to be precise about who was at fault here, because the team’s first instinct was to send a developer to “fix the links”. The site’s links were correct. The category links were clean absolute URLs. The click handler on the listing rows only filled a subscribe form; the navigation line in it was commented out and never ran. The concatenation was happening inside the crawler. The site’s only failing was answering a malformed URL with 200 OK, which tells any crawler “valid, keep going”.

Step 3: Rule Out the DDoS Properly

A DDoS is a volume problem from many sources. So I checked the sources.

grep '10:1[0-9]:' /usr/local/apache/domlogs/example.com-ssl_log | awk '{print $1}' | sort | uniq -c | sort -rn | head -5

The busiest IP address in the entire window had made three requests. Three. The load came from more than two thousand addresses in datacenter and proxy ranges, each making two or three requests. By volume per IP, nothing was happening. No firewall rate limit on earth would have triggered.

Then I checked the user agent.

grep '10:1[0-9]:' /usr/local/apache/domlogs/example.com-ssl_log | grep -o '"Mozilla[^"]*"' | sort | uniq -c | sort -rn | head -3

7,024 of 7,027 requests shared a single string — one specific desktop Chrome build on one specific macOS version. Two thousand “different visitors” with an identical browser fingerprint is not two thousand visitors. It is one scraping operation rotating through a proxy pool, dressed as a browser.

Two more things confirmed it was a tool, not a crowd. Both incidents sat in a tight band of 676 to 718 requests per minute, every minute — organic crawling is never that even. And the tool did not identify itself as a bot, which means robots.txt was never going to help.

So: not a DDoS. One client, rate-limited by its own configuration, requesting about 11.7 pages per second.

Step 4: The Number Nobody Had Compared

Here is the question the team could not answer in that first message, and it is the whole story.

grep -E 'pm.max_children|pm.max_requests' /opt/cpanel/ea-php81/root/etc/php-fpm.d/example.com.conf

pm.max_children = 5
pm.max_requests = 20

Five. The entire site was allowed five concurrent PHP processes. At roughly half a second per page, that is a hard ceiling of about ten PHP requests per second.

The scraper was asking for 11.7 PHP requests per second. More than 100 percent of the site’s capacity, sustained for twenty minutes.

Now the chain is obvious. All five PHP-FPM slots fill. The next request waits for a slot. While it waits, it holds an Apache worker. Apache has 150 workers. Within a minute they are all holding a request that is waiting for PHP. Every connection through Apache — the site, the images, the webmail proxy — stalls. A few real requests trickle through when a slot happens to free up at the right moment, which is why the outage was severe but never quite total.

Apache never crashed because Apache was never the bottleneck. It was the waiting room.

Why 20 Percent More Traffic Took the Site Down

This is the part that genuinely surprised the team. The site normally served around 35,000 requests an hour at peak. The scraper added about 42,000 an hour. More, yes, but not ten times more. How does a modest increase cause a total outage?

Because the two numbers are not the same kind of request.

Normal traffic is mostly images, CSS and JavaScript. Apache serves those from disk without touching PHP. A busy hour of real visitors might generate only a few PHP requests per second. The scraper’s traffic was 100 percent PHP, and because every URL was unique, nothing was ever served from cache. Every single hit ran the application from scratch.

Compare PHP request rates, not total request rates. Total requests per hour is the number everyone quotes and the number that tells you nothing about PHP capacity.

A warning if you go looking for this on your own server: measure during the flood, not after. When I ran the listing page on the idle server it answered in half a second and looked perfectly healthy. The pages were never slow to process. They were waiting for a slot that never opened.

How to Actually Fix This

There were two independent problems. The scraper alone would have been harmless if the page did not mint infinite URLs. The infinite URLs alone would have been harmless without the scraper. Fixing either one breaks the outage. Fix both.

Step 1: Reject malformed URLs at the door.

Any request whose query string contains a second ? is malformed by definition, so refusing it carries no risk to legitimate traffic. Two lines in the site’s .htaccess:

RewriteEngine On
RewriteCond %{QUERY_STRING} \?
RewriteRule ^ - [F]

Once the server answers 403 instead of 200, the crawler has nothing new to follow, and the loop collapses on its own. No code change on the page is needed, because the page was never broken.

Verify it before you trust it:

curl -s -o /dev/null -w '%{http_code}\n' 'https://example.com/page-listing?list=36?list=42'

You want 403. Then run the same check against the clean URL with one ? and confirm it still returns 200.

Step 2: Give PHP a realistic ceiling.

Five children is far too low for a site doing 35,000 requests an hour. Any genuine burst of real visitors would have caused the same outage with no scraper in sight. The server had almost 12 GB of RAM and about 9 GB free; one FPM child measured 16 MB idle, so budgeting 50 MB each leaves room for about 30. In WHM that is MultiPHP Manager › PHP-FPM pool options for the domain, or the same file we read above.

pm.max_children = 30

This change is about capacity, not about the scraper. At 30 children the ceiling rises from about 10 to about 60 PHP requests per second, so this particular scraper would no longer cause an outage — but a faster one still would. Step 1 is what stops the loop. Step 2 is what stops the next real traffic spike from looking like one.

Change pm.max_requests separately, later. The cPanel default of 20 makes every child respawn constantly; 500 is saner. Keep the two changes apart so you can tell which one did what.

Step 3: Put something back in front of the origin.

This domain had been switched to DNS-only on Cloudflare a few weeks earlier to fix a different performance problem, which quietly turned off the edge rate limiting and put the origin IP in public DNS. The scraper landed directly on the server with nothing in between. Whatever you use in front — Cloudflare, a load balancer, a WAF — make sure a per-client rate limit is actually active after every DNS change, not just the day it was set up.

The Log Gotchas That Cost an Hour

Webmail requests on this server were in the main domain’s -ssl_log, not in the webmail subdomain’s log, which had been empty for months. Identify webmail hits by roundcube or cpsess in the URL.
The live log is rotated around 17:00 and does not hold earlier days. A count of zero for an older window usually means rotation, not an outage. Confirm which hours a file covers before calling a gap real.
Apache prints a “reached MaxRequestWorkers” line once per event, not once per minute. Grepping a single minute of the error log proves nothing. Tail it and read the timeline.

What I Tell Every Customer Now

Before anyone writes “DDoS” in an incident report, I ask one question:

“What is the busiest single IP in the outage window, and how many PHP workers is the site allowed?”

If the busiest IP made three requests and the answer to the second half is a single digit, it was not an attack. It was a ceiling. And the fix is two lines in a config file, not a procurement request.

FAQs

Was it really not a DDoS? It took the site down.

No. A DDoS is a volume attack from many sources, and the firewall sees it as high request rates per IP. Here the busiest IP made three requests in twenty minutes. The outage came from one rate-limited scraper requesting about 11.7 PHP pages per second against a site that could process about 10. That is a capacity ceiling, not an attack.

Why did WHM keep working while the website was down?

WHM runs on its own daemon, cpsrvd, on port 2087, and does not pass through Apache. When Apache’s workers are all busy waiting for PHP, the website and anything proxied through Apache (such as webmail) stall, but WHM is unaffected. “WHM works” only tells you the server is up, not that the web stack is healthy.

Why was there nothing in the Apache error log?

Because nothing failed. When all workers are busy, Apache queues new connections rather than erroring. Saturation is silent. You find it in the access log by counting requests per minute and by looking at what those requests asked for, not in the error log.

Should the developer fix the page so the URLs stop growing?

Not in this case. The page’s links were correct absolute URLs; the concatenation happened inside the crawler. The one thing the site should change is to answer a URL with a second question mark with 403 instead of 200, which a two-line rewrite rule does. That removes the signal that keeps the crawler looping.

What is a sensible pm.max_children value?

Measure one idle PHP-FPM child’s memory on your server, budget about three times that per child to allow for real page loads, and divide the RAM you are willing to give PHP by that figure. On this server, 16 MB idle, a 50 MB budget and about 9 GB free pointed to roughly 30. Then confirm under real load, not on an idle box.

How do I know if my server is close to this ceiling right now?

Count PHP requests per second during your real peak, not total requests, and compare it with pm.max_children divided by your average PHP response time in seconds. If the peak PHP rate is more than about half of that ceiling, you are one scraper or one marketing campaign away from an outage.

Download the PDF

Originally published at quabin.com.

Load Testing the Server Before Deploying Your Critical App

Daanial Farrukh — Tue, 04 Aug 2026 18:13:54 +0000

A presales war story about CPU steal time — the metric almost nobody checks before go-live — and the full stress-test checklist I now run before any app touches production.

A customer once told me, with total confidence:

“We’re ready. Load testing passed, QA signed off, we’re deploying Friday.”

I asked one question: “What VM size are you deploying on, and have you checked CPU steal time under load?”

Silence. Then: “What’s steal time?”

That Friday deployment went live. By Monday, response times had tripled during peak hours, support tickets were piling up, and nobody could explain why — CPU usage on the app server looked fine. Not maxed out. Not even close.

That’s the trap. CPU steal time doesn’t show up as high CPU usage. It hides in plain sight.

What CPU Steal Time Actually Is

If your app runs on a cloud VM — AWS, Azure, GCP, or any shared hypervisor host — your VM is not the only thing running on that physical server. Other customers’ VMs share the same physical CPU cores. The hypervisor decides, moment to moment, which VM gets CPU time.

Steal time is the percentage of time your VM wanted to run on the CPU but couldn’t, because the hypervisor gave that time to a neighbouring VM instead.

Here’s the part that trips people up: your VM’s own CPU usage metric only measures what happens inside your VM. It has no visibility into the time it spent waiting outside, in the hypervisor’s queue. So you can have an app server reporting 40% CPU usage, technically “healthy,” while it’s actually being starved of the CPU cycles it needs — and every request is slower because of it.

Your VM only measures what happens inside itself. The time the hypervisor hands to neighbouring VMs never appears in your CPU usage graph.

This is the classic “noisy neighbour” problem. It’s most common on:

Burstable instance types (AWS T-series, Azure B-series) that are designed to be oversubscribed
Cheap shared-core VPS plans
Any host running close to capacity with many tenants

You can check it right now on a Linux box with:

top

Look at the %st value in the CPU line. Anything consistently above 10% means your app is losing real CPU time to other tenants — and that number gets worse exactly when you need performance most: during your own traffic spikes, because that’s usually when everyone else’s spikes too.

23.4 %st in top — nearly a quarter of this box’s CPU time is going to other tenants on the same host.

Why This Never Shows Up in Normal Testing

Here’s why so many teams miss it. Load testing usually runs in a staging environment. Staging is often on a quieter host, provisioned separately, with little or no other tenant load. The app performs beautifully. Everyone signs off.

Production is a different host, possibly a cheaper tier, possibly shared with far more noisy tenants — and the first time anyone discovers the steal time problem is when real customers are already inside the app, complaining.

The fix isn’t complicated once you know to look for it:

Check %st on the actual production instance type, not staging, under real load — not just idle.
Move to dedicated-core instances (e.g. AWS m/c/r families instead of the t family) for anything customer-facing and latency-sensitive.
Alert on steal time, not just CPU usage. Set a CloudWatch or Azure Monitor alarm on it. Most teams alert on CPU% and never even collect steal time as a metric.
If you must use burstable instances, understand your CPU credit balance and what happens when it runs out — that’s a related but separate trap.

That customer from the story above moved their app server from a t3.medium to an m6i.large two weeks after launch. Steal time went from spiking above 30% during peak hours to a flat 0%. No code changed. The app was never the problem.

The Bigger Lesson: Steal Time Is Just One Item on a Longer List

CPU steal time is the one nobody checks. But it’s not the only thing that passes fine in staging and breaks in production. Here’s the full checklist I now walk through with every customer before a go-live date gets locked in.

1. CPU steal time (covered above). Test on the actual production instance family, under real concurrent load, not idle.

2. Check where your CDN edge actually is. If your site sits behind Cloudflare, the edge serving your visitors is not always in your country. When the edge sits in a different region from both your users and your origin, every request takes an international round trip, and page loads can slip by whole seconds. Open https://yourdomain.com/cdn-cgi/trace and compare colo= (the Cloudflare edge serving you) against loc= (your own location). If those two are far apart, you are paying that latency on every single asset.

3. Disk IOPS and latency. Cloud disks (EBS gp3, Azure managed disks, and so on) have provisioned IOPS and throughput caps. An app that writes logs, session data, or database records can silently queue up once it hits the disk’s IOPS ceiling — and the symptom looks like “the app is slow,” not “the disk is throttled.” Check your disk’s IOPS and throughput limit against what your app actually generates at peak load, not average load.

sudo fio --name=iops-test --directory=/root --size=1G --numjobs=4 --rw=randwrite --bs=4k --iodepth=32 --ioengine=libaio --runtime=60 --time_based --group_reporting

In plain words: this starts 4 parallel jobs, each writing its own 1 GB file into /root — 4 GB in total — in 4 KB blocks, and it keeps writing for 60 seconds. At the end it gives you a reading. Two numbers matter:

IOPS — writes per second. You will see something like iops: min=4749, max=448901, avg=31436.63. Judge the disk on avg — about 31,000 writes per second here. The min of 4,749 is the single worst sample: useful as a warning about how bad the dips get, but it is not the disk’s normal speed.
Latency — how long one write takes to finish. The value to read is clat, completion latency: clat (usec): min=18, max=18354k, avg=5319.06. That max is 18,354,000 microseconds — over 18 seconds for a single write. An average of 5 ms is healthy; an 18-second outlier is something your app will feel.

4. Network bandwidth and connection limits. Cloud instances have a documented per-instance network throughput cap, and it usually scales with instance size — look it up on your provider’s spec sheet for the exact instance type going to production. To see what the box actually gets, install a speed test on it:

sudo snap install fast

Then just type fast and hit enter. That gives you real download throughput from the server, which is enough to catch a box performing nowhere near its rated bandwidth. It will not tell you your concurrent connection ceiling, though — for that, check the limits on whatever sits in front of the app (load balancer, nginx worker_connections, database max_connections) against your real peak.

5. 502 / 504 gateway errors and the OOM killer. When the box runs out of RAM, or a sudden spike hits, Linux has no choice but to kill a process — and it goes for the one using the most memory, which is very often the database. The DB dies and restarts, and while it is coming back your workers and agents cannot open a connection to it. What you see at the front is a 502 or 504, which looks like a web server problem and is not.

dmesg -T | grep -i 'killed process\|out of memory'

6. Autoscaling trigger behaviour. Don’t just confirm autoscaling is “enabled.” Test it. Push real load and watch the scale-out actually happen. Many teams discover, only during a real incident, that their scaling policy’s cooldown period is too long, or that the metric it scales on (CPU%) doesn’t reflect the real bottleneck — which, as above, might be steal time, disk, or connections instead.

7. Failure and degradation paths, not just the happy path. Kill a dependency mid-test. Cut off the database. Throttle the cache. A stress test that only proves the app is fast when everything works tells you nothing about what happens the moment one thing doesn’t — and in production, something always eventually doesn’t.

8. Third-party API rate limits. If your app calls out to a payment gateway, SMS provider, or any external API, confirm their rate limit against your real peak concurrent call volume. This is invisible in staging if staging uses a sandbox key with a different (often higher) limit than production.

What I Tell Every Customer Now

Before I sign off on any go-live date, I ask one question that covers most of this list in one shot:

“Have you load tested on the exact production instance type, at 2x your forecasted peak concurrency, while deliberately breaking one dependency at a time?”

If the answer is yes, they’re in good shape. If the answer is “we tested on staging and it was fine,” we’re not done yet — and now you know exactly what to go check first.

Originally published at quabin.com — field notes from a presales solutions architect.

The cPanel Mail Server Hardening Checklist I Never Skip

Daanial Farrukh — Sat, 27 Jun 2026 18:11:17 +0000

You work hard for your business, and all the while leads are slipping away — leads that never reached you — because of how the email server was set up. And the greater irony? Nobody knows it’s happening.

One of my clients recently asked me to diagnose a problem. The message was short:

“Hi Daanial, we’re not receiving email sometimes from one particular sender. Can you please look into it and fix or diagnose what’s wrong?”

Simple enough. So I opened the mail logs — and my heart sank. More than 8,000 emails had been discarded at the SMTP level: refused at the front door before they ever reached a single inbox. The customer had no idea. As far as they could tell, those messages were simply never sent.

That is the quiet killer of email hosting. It isn’t a dramatic outage you can see — it’s a loss of revenue you never knew you had.

That afternoon is exactly why I built the checklist in this article. It’s a must-read for email hosting providers, and a good read for anyone who cares whether email actually gets delivered. Below is every step I now run on a cPanel mail server before it ever touches a customer’s domain — in plain language.

First, think in layers — not one magic switch

The biggest mistake I see is treating email security as a single setting. It isn’t. A hardened mail server checks every message at several points, like a building with a guest list, a metal detector, and a locked back door. If one layer misses something, the next one catches it.

Every incoming email passes through several checkpoints before it reaches the inbox.

Step 1 — Switch on the spam engine

The first thing I do is turn on Apache SpamAssassin for the whole server. Out of the box it’s often off, or only on for some accounts. I force it on globally so no mailbox is left unprotected. In WHM: Home › Email › Apache SpamAssassin → Forced Global ON.

WHM: turning Apache SpamAssassin on for the entire server.

Plain takeaway: this is the smoke detector for email.

Step 2 — Tune the spam score so you don’t lose real mail

A spam filter that’s too aggressive is worse than no filter, because it eats real email. In cPanel, under Spam Filters › Spam Threshold Score, set it to “Passive — Only Very Obvious Spam (10)”. The higher the number, the more lenient — a value of 10 means only the most blatantly spammy messages get flagged.

Setting the spam threshold to 10 so genuine mail is never lost to false positives.

Plain takeaway: start lenient. You can always tighten later — but you can never un-lose a customer’s email.

Step 3 — Add the global “known bad sender” lists

Blocklists (RBLs) are shared, worldwide lists of IP addresses already caught sending spam. I switch on the two I trust most — Spamhaus and SpamCop — under Exim Configuration Manager › RBLs.

Enabling the Spamhaus and SpamCop blocklists in WHM.

One catch that trips up almost everyone: Spamhaus refuses to answer if you query it through a public DNS like Google’s 8.8.8.8. The server must use its own local resolver:

# point the server at its own resolver
rm -f /etc/resolv.conf
echo "nameserver 127.0.0.1" > /etc/resolv.conf
chattr +i /etc/resolv.conf   # lock the file so nothing overwrites it

Then prove it works — this test query should return a result:

dig @127.0.0.1 2.0.0.127.zen.spamhaus.org +short

Plain takeaway: blocklists stop the worst senders for free — but only if your server asks them the right way.

Step 4 — Make the server verify DKIM on incoming mail

DKIM is a digital signature legitimate senders attach to their email. Verifying it on incoming mail confirms a message really came from who it claims. Find it in WHM under Exim Configuration Manager › Basic Editor.

Turning on DKIM verification for incoming mail in Exim.

Plain takeaway: this is how the server checks a sender’s ID card instead of taking their word for it.

Step 5 — Put a guard on attachments (antivirus)

Spam is annoying; a virus is a liability. Install an antivirus/anti-malware scanner (ClamAV) so every attachment is checked before it lands in a mailbox: Home › cPanel › Manage Plugins.

Installing the ClamAV antivirus scanner from WHM’s plugin manager.

Plain takeaway: the metal detector for attachments.

Step 6 — Stop your own server from becoming the spammer

One mailbox password leaks, an attacker logs in, and the server sends tens of thousands of spam messages in an hour — that’s how servers get blocklisted. Three settings in WHM Tweak Settings do the heavy lifting:

Cap hourly emails per account. One hacked account can no longer blast the internet.
Reject mail instead of silently dropping it. Silent dropping means email vanishes and nobody knows why.
Fail immediately instead of queueing. Bad mail is refused on the spot.

Setting a maximum number of emails each account can send per hour.

Reject undeliverable mail and fail immediately, rather than discard or queue it.

Outbound rate-limiting and sender tracking to catch a compromised account early.

Plain takeaway: a good host doesn’t just block incoming spam — it makes sure it can never be the SOURCE of spam.

Step 7 — Get the server’s identity right

Big mail providers are suspicious of servers that look anonymous. I always set:

A real hostname (e.g. your-host.example.com).
Matching reverse DNS (PTR) — ask your datacenter. Mismatched rDNS is an instant spam signal.
A fresh SSL certificate (cPanel › SSL).
The correct server time.
A complete DNS record set: A (root, www, mail, webmail), MX, and — most importantly — SPF, DKIM, and DMARC.

Those last three are the trust trio: SPF says which servers may send for your domain, DKIM signs your messages so they can’t be forged, and DMARC tells the world what to do if a message fails. Skip them and your mail lands in spam, full stop. One more Exim tweak: reject remote mail sent to the server’s own hostname.

Plain takeaway: a server with a clean, honest identity gets trusted.

Step 8 — Lock the doors (firewall rules)

Think of the firewall as a guest list for the building: visitors come in through their own doors, the control room opens only for staff, every other door stays locked.

The firewall guest list: who can reach which port on the server.

Website traffic (80, 443): ideally only from Cloudflare’s IP ranges.
Email ports (25, 465, 587, 993, 995): open to all.
cPanel 2083 / WHM 2087 / SSH 22: restricted to the admin’s own IP only.
Everything else: denied by default; outbound allowed.

One more lock I never skip: turn on Two-Factor Authentication (MFA) for WHM under Home › Security Center › Two-Factor Authentication. Even if someone steals the password and is on an allowed IP, they still can’t get in without the code from your phone.

Plain takeaway: open the doors people need, lock the rest, add MFA on the admin door.

Step 9 — Make webmail fast and reliable

Security that makes email painfully slow won’t last. In Dovecot I disable IPv6 if unused, set spare auth processes to 10 / max to 100, tune LMTP concurrency and cache, and use balanced compression. I also raise PHP limits (execution 300s, memory 512 MB, upload/POST 100 MB), and on an email-only box I stop the cPanel PHP-FPM service for a lighter Roundcube.

Plain takeaway: a hardened server should still feel fast.

Step 10 — The gotcha that bites everyone: port 25

Remember the 8,000 emails my client lost? This is the kind of thing that causes it. Mail “just hangs” — no error, no bounce — and the server looks spotless. The datacenter’s network can quietly drop inbound connections on port 25 before they reach your server, so messages are discarded at the SMTP level and nobody is told. Ask your datacenter/NOC to whitelist inbound SMTP (port 25) for your server’s IP. Before you call, confirm what you’re seeing:

grep -i "data timeout" /var/log/exim_mainlog | tail -10

Lines like “SMTP data timeout (message abandoned)” mean mail reached you but got cut off mid-transfer — a network-path problem, not the mailbox.

Plain takeaway: sometimes the mail server is perfect and the network is the villain.

Step 11 — Prove it works, then keep it current

Force a full update so every component is patched:

/usr/local/cpanel/scripts/upcp --force

Then confirm the auto-update cron is scheduled:

grep -R "upcp" /etc/cron* /var/spool/cron* 2>/dev/null

Plain takeaway: hardening is not a one-time event.

The bottom line

None of these steps is hard on its own. The value is in doing all of them, every time, in the same order — so no server ever ships with the factory defaults still on.

📋 A printable PDF version of this entire checklist is available here.

Originally published at quabin.com.

Your Customer Thinks Their Site Has HTTPS. It Probably Doesn't.

Daanial Farrukh — Wed, 03 Jun 2026 17:40:13 +0000

A presales story about the Cloudflare SSL setting almost everyone gets wrong — and how to verify, with proof, that you've actually fixed it.

A few weeks ago, I was in a workshop with a customer's CTO and his technical team. The room was confident. They had spent the last month tightening their stack, ticking off security items one by one. Authentication — done. WAF rules — done. Logging — done.

Then I got to the question I always ask: "Is encryption in place?"

"Yes," the CTO said. "We're on HTTPS."

"How are you managing it?"

"Through Cloudflare."

It was an incomplete answer, and I wanted to clear my own head, so I asked the obvious follow-up: "How?"

"We've enabled Cloudflare's free SSL by keeping the proxy on."

"And?"

The CTO looked at me. "And what?"

Everyone in the room turned to me. I looked back at them — in shock.

Because what they had configured wasn't end-to-end encryption. It was something much weaker. And every single person in that room thought it was the same thing.

This article is for every CTO, architect, and engineer who has ever clicked the orange cloud icon, switched on Cloudflare SSL, and assumed the job was finished. It isn't. And the gap between what you think you have and what you actually have is exactly the kind of gap attackers wait for.

I'll walk you through the misconception, the fix, and — critically — how to verify that the fix actually works. I even set this up on quabin.com, so every command and screenshot below is from a real, running production configuration.

The Misconception That Lives Behind the Orange Cloud

If you believe you are protected just because you proxied your domain through Cloudflare and "SSL is in place," you are doing half the work. And in cyber security, half the work is no work.

Here's why.

When you put Cloudflare in front of your website, two distinct network connections come into existence — not one:

Visitor → Cloudflare — the browser talks to Cloudflare's edge.
Cloudflare → Origin — Cloudflare talks to your actual server (your VM on AWS, Hetzner, your hosting provider, wherever it lives).

The padlock you see in the browser bar reflects only the first connection. It tells the user nothing — absolutely nothing — about what happens between Cloudflare and your origin server.

Most teams configure the first connection correctly and never look at the second one. And that's where the breakdown lives.

If the second leg is unencrypted, your traffic — login credentials, customer PII, session tokens, payment data, whatever flows through — passes through every router, ISP, and intermediate network between Cloudflare's data center and yours, in plaintext. A man-in-the-middle on any of those hops can read it, modify it, or sell it on the dark web. We hear about these breaches every quarter. This is one of the ways they happen.

The Cloudflare SSL Modes — and Which One You're Actually On

Cloudflare offers five SSL/TLS settings — one automatic and four manual. Most teams never look past the one they picked on day one, and that early choice is usually wrong for production.

1. Automatic — This is now Cloudflare's default mode, and it's quietly impressive engineering. For years Cloudflare ran a separate tool called SSL Recommender that scanned each origin's TLS capability and prompted the user to pick the safest setting. Most users ignored the prompts. So Cloudflare went a step further: Automatic mode now performs that same check on every site by default. The moment it detects an origin that can handle TLS, it upgrades the connection to Full (option 4 below) — without breaking the site or surfacing a single certificate error to the user. It's the kind of pragmatic engineering most platforms don't bother to ship.

2. Off — No encryption anywhere. Self-explanatory. Don't use this in production.

3. Flexible — Encrypted from visitor to Cloudflare. Plaintext from Cloudflare to your origin. This is the trap. The browser shows the padlock. The user feels safe. Your traffic is exposed on the back half of the journey.

4. Full — Encrypted both legs. But Cloudflare does not validate your origin's certificate. A self-signed certificate works. So does an expired one. So does an attacker's certificate if they manage to intercept the connection. Better than Flexible — but still vulnerable to man-in-the-middle (MitM) attacks. If you assume no one would bother running such an attack on your traffic — that assumption is exactly the false sense of security this mode creates.

5. Full (Strict) — Encrypted both legs and Cloudflare validates the origin's certificate against a trusted chain. This is real end-to-end TLS. This is what your CTO thinks you have when they say "we're on HTTPS via Cloudflare."

Most teams I work with are on Flexible or Full when they think they are on Full (Strict). They click the orange cloud, see the padlock, ship, and move on.

What the CTO Thought vs. What Actually Happened

Here is the picture the CTO had in his head:

This is Full (Strict) mode. End-to-end (E2E) TLS. The architecture is sound. No plaintext anywhere on the wire.

Here is what was actually configured:

This is Flexible mode. The encrypted leg ends at Cloudflare's edge. From Cloudflare onwards, the traffic flows in clear plain text across the public internet to wherever the origin lives.

The terminology we use in security — "end-to-end encryption (E2E)" — was not fulfilled. The architecture was not secure. And finding the origin to attack it is not hard: an attacker can pull historical DNS records, scan certificate transparency logs, or use a handful of well-known reconnaissance techniques to identify the hosting data center, then probe the network path for an exposed link.

For any enterprise that genuinely needs to protect data in transit — and that means anyone handling cardholder data under PCI DSS, healthcare data under HIPAA, or personal data under GDPR/ISO-27018 — Full (Strict) is the only correct setting. The others are not options. They are gaps.

I Want to Honor Cloudflare Here

The work those engineers do is excellent. Cloudflare has done more to make HTTPS accessible to the average website than almost any other company on the internet.

The reason Flexible mode exists is practical: many origins genuinely cannot run TLS on day one, and Cloudflare offers Flexible so those sites can still get partial protection while they figure the rest out. If Cloudflare forced Full (Strict) as a default, a large share of new users would hit complex certificate errors on day one and walk away. The setting exists for a real reason.

The core issue is that teams pick it as a permanent solution, and tell themselves they are "fully encrypted". I once flagged this exact pattern at another organization — only to find that their third-party security audit had missed it entirely, with the "encryption in transit" checkbox ticked clean in the final report.

Whenever I sit with a customer, I push to understand the traffic flow from origin to destination — every hop, every termination, every place encryption begins and ends. That single discipline surfaces more architecture problems and produces better solutions than almost any other discovery exercise I do.

How to Actually Fix This

If you read this and you don't know which mode you're in, you're probably not on Full (Strict). Here is how to get there.

Step 1: Generate an origin certificate.

The easiest path is Cloudflare's Origin CA. It's free, available from inside your Cloudflare dashboard under SSL/TLS → Origin Server → Create Certificate, and the certificate is valid for up to 15 years. The defaults are fine: RSA 2048, hostnames yourdomain.com and *.yourdomain.com.

When the certificate generates, Cloudflare will display two text blocks: the Origin Certificate and the Private Key. Save both to plain text files immediately. Cloudflare will never show the private key again, and losing it means regenerating from scratch.

Step 2: Install the certificate on your origin server.

For nginx, point ssl_certificate and ssl_certificate_key at the new files and reload. For Apache, the equivalent SSLCertificateFile and SSLCertificateKeyFile directives. On managed hosts like Hostinger, look for SSL → Install Custom SSL, paste the certificate and private key into the corresponding fields, and leave the CA bundle field empty. Cloudflare Origin Certificates do not require a CA bundle because they are not meant to be publicly trusted — only Cloudflare's infrastructure trusts them. That's the whole point.

Step 3: Switch the Cloudflare SSL/TLS mode to Full (Strict).

In your Cloudflare dashboard, navigate to SSL/TLS → Overview, and select Full (Strict). This is the single click that matters most. If your origin certificate is installed correctly, your site will continue loading without errors. If it isn't, you'll see a 525 SSL Handshake Failed error — which is itself a useful signal that the cert install needs revisiting.

Step 4: Verify with curl.

This step is where most tutorials stop and where mine starts. Open a terminal and run:

curl -vk --head --resolve yourdomain.com:443:YOUR_ORIGIN_IP https://yourdomain.com

The --resolve flag tells curl to bypass Cloudflare and connect directly to your origin server's IP, while still requesting your domain name. The -k flag tells curl to proceed even if the certificate is not trusted by your local machine.

You should see two things in the output:

A successful TLS handshake followed by HTTP/1.1 200 OK (or whatever status your homepage returns)
Response headers identifying your origin — for example, Server: LiteSpeed, platform: hostinger, or whatever your stack reports

Here's the output:

* Trying 141.xxx.xx.xxx:443...
* Connected to yourdomain.com (141.xxx.xx.xxx) port 443
< HTTP/1.1 200 OK
< Server: LiteSpeed
< platform: hostinger
< X-LiteSpeed-Cache: hit
< alt-svc: h3=":443"; ma=2592000

The handshake succeeded over TLS, the origin returned a clean 200, and the response identifies Hostinger's LiteSpeed server. That confirms the Cloudflare Origin Certificate is installed and being served correctly.

Now run the same command without the -k flag:

curl -v --resolve yourdomain.com:443:YOUR_ORIGIN_IP https://yourdomain.com

You should now see a failure with this kind of error:

schannel: SEC_E_UNTRUSTED_ROOT (0x80090325) - The certificate chain was issued by an authority that is not trusted.

This error is not a bug. It is the verification.

What it means: the Cloudflare Origin Certificate is signed by Cloudflare Origin CA, which is intentionally not trusted by browsers, operating systems, or any public PKI. Only Cloudflare's edge servers trust it. So, when you connect directly to your origin, your local machine correctly says "I don't recognize this CA, refusing to trust this connection."

That's exactly the design. It means:

Random visitors who somehow discover your origin IP and try to connect directly will be rejected by their own TLS clients
Only traffic flowing through Cloudflare will accept the certificate and proceed
Combined with Full (Strict) at the edge, you now have a closed loop — Cloudflare trusts only your origin cert, and only Cloudflare's edge talks to your origin

If you ran this curl test and the TLS handshake succeeded without -k, that means your origin is serving a publicly trusted certificate (Let's Encrypt, your host's default SSL, etc.) — which is fine but means you have not yet swapped to the Cloudflare Origin Certificate. Go back and reinstall.

Step 5 (bonus): Lock the origin down further.

Enable Authenticated Origin Pulls in Cloudflare so your origin will refuse any connection that does not present a Cloudflare client certificate. Combined with Full (Strict), this gives you mutual TLS between Cloudflare and your origin — even an attacker who got hold of your origin IP and somehow worked around the cert validation problem could not establish a connection.

The whole exercise takes an experienced engineer about an hour. Most teams put it off for years.

"But My Browser Shows a Different Certificate Than the One I Installed"

This is the question every careful reader asks after walking through the fix. I asked it myself.

You install the Cloudflare Origin Certificate on your server. You set Full (Strict). You open your site in a browser, click the padlock — and see a certificate issued by Let's Encrypt, not Cloudflare.

Did the installation fail? No. This is correct, and here's why:

There are two certificates in this architecture, serving two different connection legs:

Cert A (visitor-facing): Cloudflare automatically issues and presents this to your browser, via Let's Encrypt or Google Trust Services. It's publicly trusted. It's the cert your browser sees.
Cert B (origin-facing): The Cloudflare Origin Certificate you installed on your server. Cloudflare uses it when it talks to your origin. Browsers never see this certificate. They have no reason to.

So, when you click the padlock and see Let's Encrypt — that's Cert A doing its job. The Origin Certificate (Cert B) is invisible to the browser by design. The curl test in Step 4 is the only direct way to confirm it from outside Cloudflare.

If you don't internalize this two-certificate model, you'll be confused. Once you see it clearly, every other Cloudflare configuration question gets easier.

What Happened After

I explained all of this to the CTO and his team in that room. We walked through the modes. We drew the diagrams. We mapped what they had against what they thought they had.

The CTO was thankful. The team was thankful. Within a week they had moved to Full (Strict), enabled Authenticated Origin Pulls, and added an item to their security review checklist so this would never sit unaddressed again.

Honestly, moments like that bring me great joy. The job of a cloud presales solutions architect is not to sell the biggest possible solution. It is to ask the one question that turns a confident "we are secure" into an honest "we have work to do" — and then to help them do that work.

If you take only one thing from this article, take this: the padlock in the browser is not a guarantee of end-to-end encryption. It is a guarantee that the browser is talking to something over TLS. What that something does next is up to you to verify.

A Question to Ask in Your Next Architecture Review

The next time someone tells you "we're HTTPS, we're on Cloudflare," ask them this:

"What SSL/TLS mode are you running in Cloudflare — Off, Flexible, Full, or Full (Strict)? And have you verified the origin certificate with curl?"

If they don't know the answer to the first half, you already know the answer. They're not on Full (Strict). If they look puzzled at the second half, they haven't verified the fix even if they claim it's in place.

Help them get there. The curl one-liner takes thirty seconds and removes all ambiguity.

Originally published on quabin.com — I write about the questions I ask in real customer rooms, the ones that change architectures and surface the problems no one else noticed.