Cloudflare’s SSL/TLS encryption modes aren’t just about securing your site; they’re about controlling the trust boundary between your origin server and Cloudflare’s edge.
Let’s see it in action. Imagine you have a simple web server running on 192.0.2.100 on port 443 with a self-signed certificate.
# On your origin server, generate a self-signed certificate (for demonstration)
openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout origin.key -out origin.crt -subj "/CN=your-domain.com"
In your Cloudflare dashboard, you navigate to "SSL/TLS" -> "Overview". You’ll see these options:
- Off: No SSL/TLS between the client and Cloudflare. Cloudflare will serve HTTP to clients.
- Flexible: Encrypts traffic between the client and Cloudflare, but not between Cloudflare and your origin server. Cloudflare acts as a proxy, speaking HTTP to your origin.
- Full: Encrypts traffic between the client and Cloudflare, and between Cloudflare and your origin server. Your origin server must have a valid SSL certificate (self-signed is not valid for this mode).
- Full (Strict): Encrypts traffic between the client and Cloudflare, and between Cloudflare and your origin server, and Cloudflare validates that your origin server’s certificate is issued by a trusted Certificate Authority (CA) and is not expired.
If you choose Flexible with the setup above, Cloudflare will connect to your origin via HTTP on port 80.
# On your origin server, you might see a request like this (simplified)
# curl -I http://192.0.2.100:80
# HTTP/1.1 200 OK
# Server: nginx/1.18.0
# ...
However, if you select Full and your origin only has a self-signed certificate, Cloudflare will refuse to connect.
# Cloudflare logs might show an error like this, or your site will appear offline
# Error: SSL handshake failed with origin (e.g., 525, 526)
The problem this solves is multifaceted. Historically, SSL/TLS was a performance bottleneck and an operational headache, especially managing certificates on every origin server. Cloudflare’s modes allow you to offload that complexity. Flexible is the easiest to set up but the least secure, as your data is unencrypted between Cloudflare and your server. Full adds encryption to your origin connection but relies on your server having some certificate, even if untrusted. Full (Strict) is the most secure, ensuring end-to-end encryption with verified certificates.
The internal mechanism at play is how Cloudflare establishes its connection to your origin server. When you choose Full (Strict), Cloudflare’s edge servers act as a client attempting to connect to your origin’s IP address and port. They perform a full TLS handshake, including verifying the certificate presented by your origin against a trusted list of CAs. If your origin presents a self-signed certificate, or one from an unknown CA, or an expired one, the handshake fails.
This is why Full (Strict) is the recommended setting for most production environments. It ensures that even if a malicious actor were to compromise a network hop between Cloudflare and your origin, they couldn’t eavesdrop on the traffic. Cloudflare can fetch your site’s content securely, and then deliver it securely to the end-user.
Consider the scenario where you have a load balancer in front of your origin servers, and that load balancer handles SSL termination. In this case, your origin servers themselves might be running on HTTP, but the connection to the load balancer is secured. Cloudflare, configured for Full (Strict), would connect to the load balancer’s IP address. The load balancer would present a valid certificate to Cloudflare, satisfying the Full (Strict) requirement. The key is that the first hop from Cloudflare must present a valid, trusted certificate.
The one thing most people don’t realize is that even with Full (Strict), if your origin server’s IP address is different from the IP address listed in its SSL certificate’s Subject Alternative Name (SAN) or Common Name (CN), Cloudflare will reject the connection. This is a common pitfall when using load balancers or dynamic IP assignments where the IP might change, but the certificate is bound to a hostname. Cloudflare essentially performs a DNS lookup for your origin hostname and then tries to connect to the resolved IP, expecting the certificate presented at that IP to be valid for the hostname it resolved.
The next step is understanding how to configure Authenticated Origin Pulls to further secure the connection between Cloudflare and your origin.