Skip to content

← Blog

Cloudflare Flexible SSL Risks: Test the Origin with curl and OpenSSL

By Nick Phillips, Founder

Cloudflare Flexible SSL Risks: Test the Origin with curl and OpenSSL

Hand-drawn SSL connection title card

Flexible SSL encrypts only the client to Cloudflare leg of a connection, which means traffic between Cloudflare and your origin server travels as plain HTTP. If you’re running this mode on a production site, the fix is straightforward: verify your origin supports TLS, then switch to Full or Full (strict) using a proper origin certificate. Left as is, Flexible exposes you to eavesdropping, redirect loops, and compliance failures.

TL;DR:

  • For payment, login, or personal data flows, PCI DSS requires encryption on every relevant hop, plus a valid origin certificate and documented coverage.
  • Install and test origin TLS first, switch to Full, then use Full (strict) after validating the certificate; check SNI when multiple certificates share an IP.
  • If your application ignores the forwarded protocol header, it may see HTTP, trigger redirect loops, mislabel cookies, or generate insecure asset links and canonical tags.
  • A temporary exception belongs only in staging or a brief maintenance window; restrict origin access by IP, set a deadline, and monitor logs.
Otterwatch
Keep Origin Certificates on Your Radar
Otterwatch watches SSL certificates and checks that your sites are up, with calm alerts before certificates expire.
Visit Otterwatch

Table of Contents

How Flexible mode works under the hood

Picture the connection as two separate hops. The first hop runs from the visitor’s browser to Cloudflare’s edge, and this leg gets real TLS: a handshake, a certificate, encryption in transit. The second hop runs from Cloudflare’s edge to your origin server, and in Flexible mode, that leg is plain HTTP. No handshake, no certificate, no encryption. Your server never sees TLS at all.

Cloudflare still forwards some information about the original request so your application can make sense of what happened upstream:

  • CF-Visitor header: a JSON object telling your origin what scheme the visitor actually used (usually {"scheme":"https"}).
  • X-Forwarded-Proto header: a more standard proxy header carrying the same kind of information.
  • Neither header is encryption. They’re hints your application can read, but the wire between Cloudflare and your server stays unprotected regardless of what they say.

This matters for anything your server does based on protocol. If your app checks the actual connection instead of these headers, it sees HTTP and may act like the request was never secure, triggering redirects, cookie flag mismatches, or broken assumptions about which requests are safe.

Concrete security risks Flexible introduces

The padlock in the address bar tells visitors their connection is secure. With Flexible, that’s only half true: the browser to Cloudflare leg is encrypted, but anything happening between Cloudflare and your server is not. A visitor sees a secure site. Your server receives naked HTTP.

That gap creates real attack surface:

  • Eavesdropping on the origin leg: anyone positioned between Cloudflare’s edge and your server (a compromised network segment, a misconfigured internal proxy, a hosting provider issue) can read traffic in plain text, including session cookies, form submissions, and authentication tokens.
  • Tampering with responses: an attacker on that path can modify content in transit, injecting malicious JavaScript or altering CSS before it reaches Cloudflare and gets served to visitors with a trusted padlock.
  • Misleading trust signals: because the browser shows a secure connection, phishing-style attacks that exploit the unencrypted origin leg are harder for visitors (and even for your own team) to spot.
  • Session and credential exposure: login forms, password resets, and checkout flows that send sensitive data to an HTTP origin put that data at risk the moment it leaves Cloudflare’s network.

The blast radius grows fast on shared hosting, in data centers with other tenants, or in any environment where you don’t fully control the network path to your server. OWASP’s TLS guidance recommends end-to-end TLS precisely because any unencrypted segment, no matter how short, becomes a point where data can be read or altered without the end user ever knowing.

Flexible SSL leaves the Cloudflare to origin connection unencrypted, which is the core reason Cloudflare’s own documentation and community guidance steer production sites away from it. A single unprotected hop undoes the protection you’re paying for on the other side of the connection.

Operational symptoms and common failures caused by Flexible

Flexible doesn’t just create a security gap. It breaks things in ways that are easy to misdiagnose if you don’t know what to look for.

  1. Redirect loops: your application enforces HTTPS based on what it sees from the server, which is HTTP. It redirects to HTTPS. Cloudflare, which already served HTTPS to the visitor, forwards the request as HTTP again. The loop repeats until the browser gives up with a “too many redirects” error.
  2. Mixed content and broken assets: pages that reference HTTP resources, or that generate links based on a server-side HTTP assumption, trigger browser warnings or outright block images, scripts, and stylesheets on an otherwise HTTPS page.
  3. Caching and SEO side effects: cached HTML with stale HTTP links, or canonical tags pointing at the wrong scheme, can quietly confuse crawlers and create duplicate-content signals that hurt how your pages get indexed.
  4. Protocol mismatches in logs: request traces will show HTTPS at the edge and HTTP at the origin, which is the clearest signal that Flexible is active and causing the behavior you’re troubleshooting.

Many of these redirect loops trace back to how your CMS or framework handles proxy headers. The WordPress developer documentation on HTTPS walks through exactly this interaction: when the server’s apparent protocol doesn’t match what Cloudflare already delivered, the application keeps redirecting to a scheme it thinks it’s missing. Reading X-Forwarded-Proto correctly during any Flexible to Full migration is often the difference between a clean cutover and an afternoon of debugging.

Compliance and payment-processing implications

If your site touches payment data or other regulated information, Flexible isn’t a configuration preference, it’s a compliance gap. PCI DSS requires strong encryption for cardholder data in transit across open, public networks, and an unencrypted Cloudflare to origin hop falls outside that requirement regardless of how secure the client-facing leg looks.

Auditors reviewing a PCI scope will generally check for:

  • End-to-end TLS on every hop that carries cardholder or authentication data, not just the visitor-facing connection.
  • A valid, current origin certificate rather than a self-signed or expired one sitting unnoticed behind the CDN.
  • Documentation showing the encryption method used on each segment of the request path, including between CDN and origin.
  • No unencrypted fallback paths, even temporary ones, on anything in the payment or login flow.

End-to-end TLS stops being optional the moment checkout pages, account logins, or any form collecting personal data are involved. Flexible might pass as a quick fix for a marketing landing page, but it will not pass a real audit on anything handling sensitive data.

Step-by-step migration: install origin TLS and move to Full (strict)

Moving off Flexible is mostly about sequencing. Do it in the wrong order and you’ll trade one outage for another.

  1. Choose an origin certificate. Cloudflare Origin CA is a solid option when your origin is only ever reached through Cloudflare. Let’s Encrypt via ACME works well for origins that need a certificate validated independently of Cloudflare. A standard CA certificate from your hosting provider is a reasonable third path if you already manage certs that way.
  2. Install the certificate on your origin server and confirm it binds correctly to the right virtual host and port 443.
  3. Verify the origin serves HTTPS directly, before touching Cloudflare’s settings, so you know the server side is solid independent of the CDN.
  4. Switch Cloudflare’s SSL mode to Full, confirm the site still loads correctly, then move to Full (strict) once you’ve confirmed the origin certificate is valid and trusted (not self-signed, unless you’re specifically using Cloudflare Origin CA, which Cloudflare trusts by design).
  5. Watch for redirect loops or mixed content in the minutes after the switch, and have a rollback plan ready: reverting to Full (non-strict) briefly if the certificate chain throws unexpected errors.

Double-check SNI configuration if your origin hosts multiple certificates on the same IP, since a mismatched SNI response is one of the more common reasons a Full (strict) cutover fails on the first try.

Pro Tip: Test the origin certificate directly against your server’s IP before flipping Cloudflare’s mode, so you’re not debugging two systems at once.

Our own SSL certificate best practices guide for small business sites walks through picking between these origin certificate options in more detail if you’re deciding which one fits your setup.

Diagnostics: curl, openssl, and browser checks to verify where TLS ends

Before you trust that a migration worked, prove it.

  • curl -v https://yourdomain.com shows you the full handshake and response headers from the visitor’s point of view.
  • curl --resolve yourdomain.com:443:ORIGIN_IP https://yourdomain.com -v forces curl to hit your origin directly, bypassing Cloudflare, so you can confirm the origin itself answers on HTTPS.
  • openssl s_client -connect ORIGIN_IP:443 -servername yourdomain.com shows the certificate chain, the negotiated TLS version, and whether SNI is being handled correctly.
  • Browser devtools’ Network tab will flag mixed-content warnings and show you exactly which requests dropped to HTTP, along with any redirect chains that loop.

If curl --resolve against your origin IP returns a connection refused or a certificate error, your origin isn’t ready for Full (strict) yet, no matter what Cloudflare’s dashboard says.

Our SSL debugging checklist and this guide to diagnosing redirect loops both go deeper into reading these outputs if you hit something unexpected.

Preventive ops: certificate monitoring and why it stops teams reverting to Flexible

Flexible often gets switched on as a panic button: a certificate expired, the chain broke, and someone needed the padlock back fast. That’s the pattern worth breaking, not just the setting.

Watching for expiry windows, unexpected certificate transparency log entries, and sudden chain changes catches the problems that otherwise turn into a 2 AM Flexible fallback. Catch the expiring cert three weeks out instead of the morning it lapses, and there’s no emergency pushing anyone toward an insecure shortcut.

Preventive ops: certificate monitoring and why it stops teams reverting to Flexible — overview diagram

A pragmatic view on short-term exceptions

Flexible isn’t automatically a disaster if you timebox it tightly: a staging environment, a short maintenance window, nothing touching real user data. If you do lean on it briefly, restrict access to the origin by IP, set a hard deadline, and watch the logs closely until the real certificate is in place.

What it should never be is a permanent setting on a production site handling logins, forms, or payments. Treat it as a bandage, not an architecture.

— Nick Phillips

How Otterwatch keeps you from needing Flexible in the first place

We built Otterwatch around one quiet job: catching a certificate problem weeks before it becomes a 2 AM scramble. A plain heads up email beats a dashboard full of red alerts, and it beats reaching for Flexible as a panic fix even more.

Otterwatch

  • Expiry alerts land before a certificate lapses, not after a visitor reports a browser warning.
  • Monitoring can cover reachability too, so a dead origin can show up alongside certificate health.
  • There is a free plan covering multiple domains without requiring a credit card.
Plan What’s included Price
Free Monitor multiple domains, expiry and uptime alerts No published price
Pro Additional certificate monitoring and change detection Prices on the pricing page

Check your current setup with the free SSL certificate checker, or see what fits on the pricing page.

FAQ

Has Cloudflare ever been breached?

Cloudflare’s own security track record isn’t the central risk here. Flexible SSL’s exposure comes from leaving your Cloudflare to origin connection unencrypted, which is a configuration choice on your end rather than a vulnerability in Cloudflare’s infrastructure.

Is SSL being phased out?

The term “SSL” is largely used informally now for what is technically TLS, since the actual SSL protocol versions were deprecated years ago. OWASP’s TLS guidance recommends defaulting to TLS 1.3 and disabling legacy versions, which is the standard most current certificates and browsers already follow.

What are the downsides of using Cloudflare?

Cloudflare itself isn’t the downside: the risk comes from configuration choices like leaving Flexible SSL enabled instead of Full (strict). Once origin TLS is set up correctly, Cloudflare’s SSL modes work as intended rather than creating the unencrypted hop described throughout this guide.

Why doesn’t everyone use Let’s Encrypt?

Let’s Encrypt works well for origins that need independent certificate validation, but some teams prefer Cloudflare Origin CA when their server is only ever reached through Cloudflare, since it’s simpler to issue and renew in that specific setup. The right choice depends on whether your origin needs to be trusted outside of Cloudflare’s network.

Sources

Catch the next cert expiry before your users do.

Otterwatch checks your SSL certificates daily and emails you 30 days before they expire. Five sites free.

Start watching →