A site behind Cloudflare can show a green padlock to every visitor while the traffic between Cloudflare and your server travels in plain text. That gap comes down to which of the Cloudflare SSL modes you pick: Flexible, Full, or Full (strict). This guide explains what each mode actually encrypts and checks, why the wrong choice causes redirect loops and 52x errors, and how to move a production site to the strictest mode without downtime.
Two Connections, Not One
A request to a proxied Cloudflare domain has two TLS legs. The first runs from the visitor’s browser to Cloudflare’s edge. The second runs from the edge to your origin server. The SSL mode only controls the second leg.
The browser sees only the edge certificate, which Cloudflare’s Universal SSL issues and renews automatically through CAs such as Let’s Encrypt and Google Trust Services. The browser has no idea what happens behind the edge. That is why the padlock tells you nothing about how the origin is protected.
How Each Cloudflare SSL Mode Works
Off sends everything over HTTP. Hardly anyone should use it, and it doesn’t work with HSTS.
Flexible encrypts browser-to-edge traffic but connects to the origin over plain HTTP on port 80. Requests from the edge to your server go out unencrypted across the public internet. It was meant for origins that can’t serve HTTPS at all. Today, with free certificates from Let’s Encrypt, there’s almost no good reason for that.
Full connects to the origin over HTTPS on port 443 but doesn’t validate the certificate. A self-signed, expired, or wrong-hostname certificate is accepted. The traffic is encrypted, but anyone who can intercept the edge-to-origin path can present their own certificate and Cloudflare will accept it.
Full (strict) connects over HTTPS and validates the origin certificate properly. It must be unexpired, chain to a trusted CA (a public CA or Cloudflare’s own Origin CA), and match the requested hostname in its SAN list. This is the only mode that protects against man-in-the-middle attacks on the origin leg.
Enterprise plans also offer Strict (SSL-Only Origin Pull), which forces HTTPS to the origin even for visitor requests made over HTTP. Since 2024, Cloudflare has also offered an automatic SSL/TLS setting that probes your origin and raises the mode when it can. Don’t rely on it to pick strict for you: when the origin certificate is broken, it settles on a weaker mode and moves on.
A Familiar Failure Scenario
A DevOps engineer moves a WordPress site behind Cloudflare. The origin already has a Let’s Encrypt certificate and an Nginx rule that redirects all HTTP to HTTPS. Cloudflare’s default setting for that zone was Flexible. Within minutes, browsers show ERR_TOO_MANY_REDIRECTS.
The cause is simple once you see it. Cloudflare requests the page over HTTP, Nginx answers with a 301 to HTTPS, the browser follows it back to Cloudflare, Cloudflare requests HTTP again, and it loops forever. Switching to Full (strict) fixes it immediately, because the origin already had a valid certificate.
The reverse failure happens months later. The certbot renewal timer on the origin stopped running after an OS upgrade. Under Full (strict), the origin certificate expires and every visitor gets Error 526: Invalid SSL certificate. Meanwhile, the edge certificate is perfectly valid. Any monitor that only checks the public hostname shows green the whole time.
Migrating to Full (strict) Without Downtime
An experienced SRE never flips the mode to strict before checking the origin. The safe order is:
1. Install a valid certificate on the origin – either a public CA certificate or a free Cloudflare Origin CA certificate (validity from 7 days up to 15 years).
2. Test the origin directly, bypassing Cloudflare: openssl s_client -connect 203.0.113.10:443 -servername www.example.com and check the verify return code, the expiry date, and the SAN entries.
3. Confirm every proxied hostname, including www, apex, and API subdomains, is covered by the origin certificate.
4. Switch to Full (strict) in SSL/TLS → Overview and watch for 525 and 526 errors in the analytics for 15-30 minutes.
5. Enable Authenticated Origin Pulls or firewall port 443 to Cloudflare’s IP ranges so nobody can bypass the edge.
For more origin checks, see the guide to checking SSL certificate health from the command line.
One edge case matters here. A Cloudflare Origin CA certificate is trusted only by Cloudflare. If you later set a hostname to “DNS only” (grey cloud), or a monitoring tool or partner integration connects to the origin directly, browsers and clients will reject it. If any traffic reaches the origin without going through Cloudflare, use a public CA certificate instead.
Myth: Full Mode Is Secure Enough
Many teams treat Full as the sensible middle ground: it’s encrypted, so it must be fine. Encryption without authentication protects against passive eavesdropping only. An attacker who controls a network hop or poisons DNS between the edge and the origin can terminate TLS with any certificate, and Full mode won’t complain.
The argument that “our origin is in AWS, so the path is trusted” doesn’t hold up either. Traffic from Cloudflare to an EC2 instance still crosses the public internet. Full is acceptable as a temporary step during migration, measured in days, not years.
Common Mistakes to Avoid
Monitoring only the edge certificate. Cloudflare renews Universal SSL itself, so edge expiry is rarely the problem. The origin certificate is what expires without anyone noticing. Monitor the origin IP or a dedicated hostname directly, and track its expiry separately from the public hostname.
Ignoring mixed content after leaving Flexible. Under Flexible, WordPress and other CMSs often think they’re running on HTTP and save http:// URLs for images and scripts. After switching modes, those hardcoded URLs remain. Cloudflare’s Automatic HTTPS Rewrites hides some of them, but the database still needs cleaning.
Using page rules to downgrade one path. Configuration Rules can set the SSL mode per hostname or path. Teams add a Flexible exception for a broken legacy subdomain, then forget it exists. Audit these rules quarterly. More pitfalls of this kind are covered in how CDN configuration can break your SSL certificate.
When the Standard Advice Doesn’t Apply
Some legacy appliances and embedded devices can’t serve TLS or only support TLS 1.0. Flexible might be the only option until the hardware is replaced. In that case, make sure the origin only accepts connections from Cloudflare IP ranges and log the exception in your risk register. Under PCI DSS or HIPAA, unencrypted transmission of cardholder data or health information over the internet won’t pass an audit, so Flexible is ruled out there completely.
Cloudflare Tunnel (cloudflared) changes the picture. The tunnel connection is already encrypted and authenticated, and the SSL mode has different meaning for services exposed through it. Check the tunnel’s origin settings instead of assuming the zone mode applies.
FAQ
Which Cloudflare SSL mode should I use?
Full (strict) for virtually every production site. Install a free Cloudflare Origin CA or Let’s Encrypt certificate on the origin and switch modes after testing it directly.
What causes Cloudflare Error 526?
Error 526 appears under Full (strict) when the origin certificate is expired, self-signed, issued for a different hostname, or missing intermediate certificates. Test the origin with openssl s_client to find the specific cause.
Does Flexible SSL hurt SEO?
Google sees the edge certificate, so rankings aren’t directly affected. The real risks are redirect loops, mixed content, and unencrypted data on the origin leg.
Summary
The padlock only describes the browser-to-edge connection. Flexible leaves the origin leg unencrypted, Full encrypts it without verifying who is on the other end, and Full (strict) both encrypts and authenticates. Move to strict, lock the origin down to Cloudflare, and monitor the origin certificate’s expiry on its own. A dead certbot timer otherwise stays invisible until visitors start seeing 526 errors.