In short
A Cloudflare SSL/TLS encryption mode controls one thing: how Cloudflare connects to your origin server. Flexible sends that second hop in cleartext HTTP. Full encrypts it but accepts whatever certificate the origin presents, including an expired or self-signed one. Full (Strict) encrypts it and requires a certificate that is unexpired, matches the hostname, and comes from a publicly trusted CA or Cloudflare's own Origin CA — the only mode that gives you authenticated end-to-end encryption. As of August 2026 the documented default for new and migrated zones is Automatic SSL/TLS, which detects what your origin supports and moves you up on its own.
Put a site behind Cloudflare and the padlock appears within minutes, usually before you've touched the origin server at all. That padlock is real, and it is also only telling you about half the journey. Cloudflare terminates the visitor's TLS connection at the edge and then makes a second, separate connection to your server — and the setting buried under SSL/TLS → Overview decides whether that second connection is encrypted, whether Cloudflare bothers checking who answered, or whether it happens in the clear while the visitor's browser reports everything as secure.
Most write-ups on this topic describe a Cloudflare dashboard from several years ago, when Flexible was the default and the four modes sat in a radio-button list waiting for you to pick one. That is no longer how it works, and the difference matters if you are debugging a redirect loop or wondering why your mode changed without anyone changing it.
What the SSL mode actually controls
The encryption mode governs the connection between Cloudflare's edge and your origin server, and nothing else. It does not affect the certificate visitors see, which is the free Universal SSL certificate Cloudflare issues for your zone. It does not change your TLS version, your cipher suites, or your HSTS policy. Change the mode and exactly one thing changes: what Cloudflare does on the way to your server.
That separation is what confuses people. A proxied request is two independent TLS decisions stacked on top of each other, and the browser only ever participates in the first one. Your visitor's padlock is a statement about the leg between them and Cloudflare. It carries no information whatsoever about the leg between Cloudflare and you — a site on Flexible with an origin serving plain HTTP over the public internet presents an identical padlock to a site on Full (Strict) with a properly validated origin certificate.
If you've read our guide to TLS termination and SSL offloading, this is the same architecture: a proxy ends the client's TLS session and opens its own toward the backend. Cloudflare is a very large, very distributed instance of that pattern, and the encryption mode is simply its name for the re-encryption policy.
Automatic SSL/TLS: the default most guides still miss
Automatic SSL/TLS is Cloudflare's documented default encryption setting as of August 2026, and it is being rolled out to zones gradually. Instead of holding one fixed mode, it uses the probes originally built for the SSL/TLS Recommender to work out what your origin can support, then applies the most secure mode available to it. If your zone hasn't been migrated yet, you'll only see the Custom SSL/TLS options, which behave exactly like the manual mode setting always has.
The probing is more careful than "try HTTPS and see". Cloudflare crawls your site with the Cloudflare-SSLDetector user agent — a trusted bot that bypasses robots.txt unless a rule targets it by name — pulls the same content over both HTTP and HTTPS, and runs a content-similarity comparison. If the two versions disagree, or if the origin is throwing 5XX errors, the upgrade doesn't proceed. Scans run roughly once a month, and stop entirely once a zone is already on the most secure mode.
When an upgrade does go ahead, it starts on 1% of traffic and climbs in 10% increments to 100%, at which point the zone's setting is permanently updated. A failure in origin connectivity part-way through aborts the whole thing: traffic rolls straight back to the previous mode and the failure is logged. Moves out of Flexible get extra caution, because switching the origin scheme from HTTP to HTTPS alters cache keys, so Cloudflare slows the ramp to let the cache warm up before resuming.
The ratchet turns one way only
Automatic SSL/TLS will never move a zone to a less secure mode. Cloudflare's documentation gives the example directly: if your origin certificate expires, a zone on Full (strict) is not quietly dropped to Full. It stays on Full (strict) and your visitors get an error page instead. Automation raises the floor; it does not catch you when you fall through it. Origin certificate expiry remains entirely your problem to monitor.
Cloudflare emails a weekly digest of upgraded zones, though currently only to Super Admins — worth knowing if you manage zones under an account where you hold a narrower role, because you will simply never see the notice. To opt a zone out and go back to manual control, set ssl_automatic_mode to custom with a PATCH to /zones/{zone_id}/settings/ssl_automatic_mode, or pick Custom SSL/TLS in the dashboard.
What each mode does
Under Custom SSL/TLS there are four modes, and they form a ladder from no encryption to authenticated encryption. Off serves everything as cleartext HTTP. Flexible encrypts the visitor leg only. Full encrypts both legs but validates nothing on the origin. Full (Strict) encrypts both legs and requires a valid, trusted, hostname-matching certificate on the origin. Cloudflare's own guidance is unambiguous: use Full or Full (Strict) if you possibly can.
Off
Setting the mode to Off redirects HTTPS requests down to plaintext HTTP. Nothing is encrypted anywhere — not between the visitor and Cloudflare, not between Cloudflare and you. Modern browsers mark such pages as not secure, and there is no realistic scenario in 2026 where this is the right choice for a public site. If you're here because something is showing a "not secure" warning, check this setting before anything else.
Flexible
Flexible gives visitors HTTPS to Cloudflare while every connection from Cloudflare to your origin is made over plain HTTP. No certificate is needed on the origin, which is the entire appeal: it's the fastest way to get a padlock onto a server that can't serve TLS. Cloudflare's own documentation advises against it for anything handling sensitive information such as personalised data or user logins.
There's a limitation here that trips up anyone running on a non-standard port: Flexible only applies to HTTPS on port 443. Traffic on other HTTPS ports falls back to Full behaviour, meaning Cloudflare will suddenly attempt an encrypted connection to an origin you never gave a certificate. A zone that "works on 443 but breaks on 8443" is usually this rule and not a firewall.
Full
Full matches the visitor's protocol: an HTTPS request from a visitor becomes an HTTPS request to your origin. The traffic is genuinely encrypted. What it isn't is authenticated — Cloudflare's documentation states that the certificate presented by the origin will not be validated in any way. Expired, self-signed, revoked, issued for a different hostname: all accepted. Cloudflare spells out the consequence too, warning that without Full (strict) a malicious party could technically hijack the connection and present their own certificate.
That makes Full a reasonable waypoint and a poor destination. It defeats passive eavesdropping on the path to your origin while leaving active interception on the table. It exists mainly for origins carrying self-signed certificates that can't be replaced yet.
Full (Strict)
Full (Strict) is Full plus certificate validation, and the validation has three specific requirements. The certificate must be unexpired, meaning the current time falls between its notBefore and notAfter dates. It must contain a Common Name or Subject Alternative Name matching the requested hostname. And its issuer must appear in Cloudflare's list of publicly trusted certificate authorities, or be Cloudflare's Origin CA. Miss any one and visitors get a 526.
Sites that need the strongest posture pair Full (Strict) with Authenticated Origin Pulls, which makes the origin verify that requests genuinely came from Cloudflare before it answers them. That closes the remaining gap — an attacker who discovers your origin's IP address and connects to it directly, bypassing Cloudflare entirely.
Why Flexible causes ERR_TOO_MANY_REDIRECTS
The loop happens when a zone is on Flexible and the origin server has its own HTTP-to-HTTPS redirect rule. Cloudflare receives the visitor's HTTPS request and fetches from the origin over plain HTTP. The origin sees HTTP, answers with a 301 to the HTTPS URL, Cloudflare relays that redirect, the browser requests the HTTPS URL again — and Cloudflare fetches over HTTP again. Nothing in the cycle changes, so the browser gives up after roughly twenty hops.
What makes this one hard to diagnose is that neither piece is misconfigured on its own. The redirect rule is exactly what every HTTPS hardening guide tells you to write. Flexible is a supported Cloudflare setting. Put them together and you get a state machine with no exit condition, which is why the symptom appears the instant a site is proxied and disappears the instant it's grey-clouded — behaviour that sends most people hunting through .htaccess for a bug that isn't there.
There are two real fixes and one that only looks like a fix. Install a certificate on the origin and move the zone to Full (Strict): Cloudflare's request then arrives as HTTPS, the origin's redirect condition is already satisfied, and the page is served on the first attempt. Alternatively, delete the origin's redirect rule and let Cloudflare issue the redirect at the edge with Always Use HTTPS, which is the approach our HTTP-to-HTTPS redirect guide recommends for any proxied site. The non-fix is turning off the origin redirect and staying on Flexible — the loop stops, and every request to your server continues travelling the public internet in cleartext.
If you run behind a load balancer rather than Cloudflare, the same failure mode shows up with a different remedy: condition the redirect on the X-Forwarded-Proto header instead of the connection scheme your origin observes.
Which mode should you use?
Full (Strict) is the answer for essentially every production site, and the only question worth spending time on is which certificate you put on the origin to get there. Use Full temporarily while migrating an origin whose certificate you can't replace today. Use Flexible only as a short bridge for a server that genuinely cannot serve TLS, and keep logins off it while you're there. Off has no legitimate use on a public site.
The sequencing matters more than the choice. Install the origin certificate first, confirm the origin answers on 443, and only then change the mode. Flip the mode first and you get an immediate 526 on a zone that was working sixty seconds earlier, which is a bad way to learn this.
One caveat about Cloudflare's automation: because Automatic SSL/TLS only upgrades, it will happily leave you on Flexible indefinitely if your origin never becomes capable of HTTPS. Nothing in the system nags you. A zone can sit on Flexible for years, passing every uptime check, serving a padlock to every visitor, with the actual traffic in the clear the entire time.
Getting a certificate onto the origin
Full (Strict) accepts two kinds of certificate on the origin: one from a publicly trusted CA, or one from Cloudflare's own Origin CA. Both are available free, both satisfy the validation, and they behave very differently outside Cloudflare. The choice comes down to a single question: does anything other than Cloudflare's proxy ever open a connection to that server?
A Cloudflare Origin CA certificate is issued by Cloudflare's private CA. Cloudflare's edge trusts it; no browser or operating system trust store contains it. Because visitors never see it — they're talking to Cloudflare's Universal SSL certificate — that doesn't matter as long as every request arrives through the proxy. It can be issued for up to 15 years, and Cloudflare notes that it does not currently send expiration notifications for these certificates, so tracking the expiry date is on you.
That "as long as every request arrives through the proxy" clause is where Origin CA certificates catch people out. Grey-cloud a DNS record to debug something and the hostname immediately throws a trust error. Point an external uptime monitor at the origin's real address and it reports a failure. Add a load balancer, a staging hostname, an API client pinned to the origin IP, or a partner's health check, and each one hits a certificate nothing outside Cloudflare will validate.
A publicly trusted certificate avoids all of that, because it validates everywhere: through the proxy, around the proxy, and on the day you decide to move off Cloudflare. That flexibility is the argument for putting one of our SSL certificates on the origin rather than a proxy-locked one — particularly on infrastructure where more than one system needs to trust that server. A DV certificate is enough for the Full (Strict) check; Cloudflare validates the chain, the dates, and the hostname, and has no opinion about the validation level above that.
Whichever you choose, the certificate has to cover the hostname Cloudflare requests. That's usually your apex domain plus a wildcard for subdomains, and it's the same SAN arithmetic covered in our comparison of wildcard and multi-domain certificates.
What shorter certificate lifetimes mean for your origin
Publicly trusted TLS certificates are on a shrinking schedule that Origin CA certificates sit outside entirely. Under CA/Browser Forum Ballot SC-081v3, the maximum validity for a publicly trusted certificate drops to 200 days on March 15, 2026, then 100 days on March 15, 2027, and 47 days on March 15, 2029. Domain validation reuse shortens alongside it, reaching 10 days in 2029. Cloudflare's Origin CA is a private CA, so its certificates are unaffected and can still be issued for 15 years.
It's tempting to read that as a straightforward win for Origin CA, and for a single-server setup that never sees traffic from anywhere but Cloudflare, it broadly is. The renewal treadmill on that hop disappears. What you're buying with it, though, is a hard dependency: the origin now holds a credential that only one company's infrastructure will accept, and the "just point DNS somewhere else for an hour" escape hatch closes.
For a publicly trusted origin certificate the answer is automation rather than avoidance. Once renewals land inside a 47-day window, a certificate you replace by hand twice a year becomes one you replace eight times a year, and manual renewal stops scaling well before then. Our guides to preparing for 47-day certificates and ACME automation with Certbot cover the mechanics, and both apply to an origin behind Cloudflare exactly as they do to a directly exposed server.
There's one Cloudflare-specific trap worth naming. ACME's HTTP-01 challenge needs Let's Encrypt to reach /.well-known/acme-challenge/ on your origin, and a proxied zone means that request goes to Cloudflare first. It usually works, but page rules, a "Under Attack" security level, or an aggressive WAF rule can quietly break the challenge and your renewal fails at 3am on a schedule nobody is watching. The DNS-01 challenge, which Cloudflare's API supports well, sidesteps the whole issue.
Errors 525 and 526: what each one tells you
Both errors appear after you move a zone to Full or Full (Strict), and they point at different stages of the same connection. A 525 means the TLS handshake between Cloudflare and your origin never completed — commonly because nothing is listening on port 443 at all. A 526 means the handshake got as far as the origin presenting a certificate and Cloudflare rejected it, which only happens in Full (Strict).
| Error | What failed | Where to look first |
|---|---|---|
| 525 | TLS handshake never completed | Is anything listening on 443? Is the firewall allowing Cloudflare's IP ranges? Does the origin support a TLS version Cloudflare offers? |
| 526 | Certificate presented but rejected | Expired certificate, self-signed certificate, hostname not in the CN or SAN, or a missing intermediate in the chain. |
| 520 | Origin returned something unexpected | Not a certificate problem. Usually the origin crashing, an empty response, or oversized headers. |
A missing intermediate is the sneaky one. A chain that a browser repairs on its own — because it happens to have cached the intermediate from another site — will still fail Cloudflare's validation, so the certificate looks fine in your browser and produces a 526 through the proxy. Our guide to the certificate chain covers assembling the full bundle correctly.
To diagnose either error, test the origin directly rather than through the proxy. From a shell, openssl s_client -connect origin-ip:443 -servername example.com shows you the exact chain Cloudflare is being handed. If the origin is publicly reachable on its own hostname, our SSL checker reports the same information — expiry, chain completeness, hostname match — without the shell. More error codes and their meanings live in our SSL certificate errors reference.
Related reading
- How to redirect HTTP to HTTPS — the origin-side rule that turns Flexible into a loop.
- What is TLS termination? — the general pattern Cloudflare's proxy is an instance of.
- 2026 certificate lifetime changes — the schedule your origin certificate now has to keep up with.
Getting to Full (Strict) is a twenty-minute job on most servers, and it's the difference between traffic that's encrypted and traffic that's encrypted to a server you've actually identified. If the origin needs a certificate that works beyond Cloudflare's proxy as well as behind it, our range of SSL certificates covers DV through EV, all of which pass the Full (Strict) check equally.