{"id":612,"date":"2025-12-08T15:35:04","date_gmt":"2025-12-08T21:35:04","guid":{"rendered":"https:\/\/blog.xbytecloud.com\/?p=612"},"modified":"2026-02-17T15:59:51","modified_gmt":"2026-02-17T21:59:51","slug":"why-pci-scans-flag-tls-issues-behind-cloudflare-and-how-to-fix-false-positives","status":"publish","type":"post","link":"https:\/\/www.xbytecloud.com\/blog\/why-pci-scans-flag-tls-issues-behind-cloudflare-and-how-to-fix-false-positives\/","title":{"rendered":"Why PCI Scans Flag TLS Issues Behind Cloudflare (and How to Fix False Positives)"},"content":{"rendered":"\n<p class=\"wp-block-paragraph\">PCI compliance scans have a way of triggering panic\u2014especially when the report comes back with <strong>dozens of findings<\/strong> tied to \u201cinsecure TLS versions.\u201d<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Recently, a customer received <strong>72 PCI scan findings<\/strong>, many of them duplicates, all pointing to deprecated TLS protocols like <strong>TLS 1.0 and TLS 1.1<\/strong>. The initial concern was understandable:<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><em>Are these real security issues, or false positives\u2014and how should we respond?<\/em><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Let\u2019s break down what actually happened, why scanners get this wrong so often behind Cloudflare, and how to resolve it cleanly.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>The Initial Concern: 72 PCI Findings (Mostly TLS-Related)<\/strong><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">The scan results showed:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Numerous findings referencing <strong>TLS 1.0 \/ TLS 1.1<\/strong><\/li>\n\n\n\n<li>Repeated entries for the same issues<\/li>\n\n\n\n<li>A concern that the server was out of PCI compliance<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">At first glance, that sounds serious.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">But context matters.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Step One: Confirm the Origin Server Configuration<\/strong><\/p>\n\n\n\n<p class=\"wp-block-paragraph\">The first thing we verified was the <strong>origin server itself<\/strong>.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>TLS 1.0 and 1.1 were <strong>already disabled<\/strong><\/li>\n\n\n\n<li>Modern ciphers and protocols were enforced<\/li>\n\n\n\n<li>No insecure TLS configuration existed at the server level<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">That immediately ruled out the most obvious risk.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">So why was the scanner still flagging it?<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>The Real Culprit: Cloudflare Edge TLS Settings<\/strong><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">The key detail: the site was running behind <strong>Cloudflare<\/strong>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">When a site is proxied through Cloudflare:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>External scanners <strong>do not test your origin server<\/strong><\/li>\n\n\n\n<li>They test <strong>Cloudflare\u2019s edge<\/strong><\/li>\n\n\n\n<li>Whatever TLS versions Cloudflare allows are what the scanner sees<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">In this case, Cloudflare was still configured to allow <strong>older TLS versions at the edge<\/strong>, even though the backend server was fully locked down.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">That mismatch is what caused the findings.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>Why This Triggers PCI False Positives<\/strong><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Most PCI scanners:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Detect <em>supported<\/em> TLS versions<\/li>\n\n\n\n<li>Don\u2019t differentiate between <strong>edge vs. origin<\/strong><\/li>\n\n\n\n<li>Flag every endpoint they test (often redundantly)<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">So even though the server was compliant, the scan results reflected <strong>Cloudflare\u2019s minimum TLS policy<\/strong>, not the server\u2019s.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">From a PCI standpoint, that still matters.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>The Fix: Enforce Minimum TLS 1.2 in Cloudflare<\/strong><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">The solution is straightforward and takes about a minute.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><strong>Steps in Cloudflare<\/strong><\/p>\n\n\n\n<ol start=\"1\" class=\"wp-block-list\">\n<li>Log in to the Cloudflare dashboard<\/li>\n\n\n\n<li>Select your website<\/li>\n\n\n\n<li>Navigate to <strong>SSL\/TLS \u2192 Edge Certificates<\/strong><\/li>\n\n\n\n<li>Set <strong>Minimum TLS Version<\/strong> to <strong>TLS 1.2<\/strong><\/li>\n<\/ol>\n\n\n\n<p class=\"wp-block-paragraph\">That\u2019s it.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Once this is applied:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloudflare stops negotiating TLS 1.0 \/ 1.1<\/li>\n\n\n\n<li>PCI scanners no longer see deprecated protocols<\/li>\n\n\n\n<li>The findings clear on the next scan<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">Cloudflare\u2019s official documentation covers this here:<br>\ud83d\udc49 <a href=\"https:\/\/developers.cloudflare.com\/ssl\/edge-certificates\/additional-options\/minimum-tls\/\" target=\"_blank\" rel=\"noreferrer noopener\">https:\/\/developers.cloudflare.com\/ssl\/edge-certificates\/additional-options\/minimum-tls\/<\/a><\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>Why ColdFusion Sites See This More Often Than Expected<\/strong><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">This issue shows up <strong>constantly<\/strong> in ColdFusion environments\u2014and not because ColdFusion is insecure.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">It\u2019s because many ColdFusion applications:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Have long lifespans (10\u201320+ years is common)<\/li>\n\n\n\n<li>Support older clients or integrations<\/li>\n\n\n\n<li>Run behind IIS with modern TLS hardening at the server level<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">Teams correctly disable TLS 1.0 and 1.1 on the <a href=\"https:\/\/www.xbytecloud.com\/coldfusion\/hosting\/coldfusion-cloud-hosting\" target=\"_blank\" rel=\"noreferrer noopener\"><strong>ColdFusion server<\/strong><\/a>, assume they\u2019re compliant, and move on.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">But when ColdFusion is behind Cloudflare, <strong>PCI scanners never see that server<\/strong>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">They see Cloudflare\u2019s edge.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">So even a fully hardened ColdFusion deployment can still fail a PCI scan if:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloudflare\u2019s Minimum TLS Version isn\u2019t enforced<\/li>\n\n\n\n<li>Edge cipher policies don\u2019t match compliance requirements<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">This creates confusion for ColdFusion teams because:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>The application server is correctly configured<\/li>\n\n\n\n<li>The scan results still look \u201cwrong\u201d<\/li>\n\n\n\n<li>The findings appear duplicated or exaggerated<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">In reality, it\u2019s a boundary issue\u2014not a ColdFusion issue.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">\ud83d\udc49 This is one of the reasons ColdFusion-specific hosting expertise matters. Knowing <em>where<\/em> TLS enforcement must occur is just as important as knowing <em>how<\/em> to configure the application itself.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>PCI compliance scans have a way of triggering panic\u2014especially when the report comes back with [&hellip;]<\/p>\n","protected":false},"author":2,"featured_media":621,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_seopress_robots_primary_cat":"none","_seopress_titles_title":"","_seopress_titles_desc":"","_seopress_robots_index":"","footnotes":""},"categories":[18],"tags":[],"class_list":["post-612","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-coldfusion"],"_links":{"self":[{"href":"https:\/\/www.xbytecloud.com\/blog\/wp-json\/wp\/v2\/posts\/612","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.xbytecloud.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.xbytecloud.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.xbytecloud.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.xbytecloud.com\/blog\/wp-json\/wp\/v2\/comments?post=612"}],"version-history":[{"count":1,"href":"https:\/\/www.xbytecloud.com\/blog\/wp-json\/wp\/v2\/posts\/612\/revisions"}],"predecessor-version":[{"id":616,"href":"https:\/\/www.xbytecloud.com\/blog\/wp-json\/wp\/v2\/posts\/612\/revisions\/616"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.xbytecloud.com\/blog\/wp-json\/wp\/v2\/media\/621"}],"wp:attachment":[{"href":"https:\/\/www.xbytecloud.com\/blog\/wp-json\/wp\/v2\/media?parent=612"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.xbytecloud.com\/blog\/wp-json\/wp\/v2\/categories?post=612"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.xbytecloud.com\/blog\/wp-json\/wp\/v2\/tags?post=612"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}