Cloudflare error 525 and 526: fix the SSL handshake to your server

Error 525, "SSL handshake failed", means Cloudflare received the visitor's request but could not complete a secure TLS connection with your own server, the origin. Error 526, "Invalid SSL certificate", means the connection worked but your origin's certificate failed validation while Cloudflare's SSL mode is Full (strict). In both cases the visitor's side is fine, and the fix is on your server: a valid certificate on port 443 and the right SSL mode. This guide shows how to tell which part is broken, how to fix it with a free Cloudflare Origin CA certificate or Let's Encrypt, and how to verify it. For how certificates and handshakes work in general, see what an SSL certificate is and how HTTPS works.

Quick answer

• Visitor: there is nothing to fix on your device. The site's server is misconfigured; try again later or tell the owner.
• 525: Cloudflare cannot finish a TLS handshake with your origin. Usual causes: no certificate for the host name on port 443, port 443 closed or serving plain HTTP, or no SNI support.
• 526: the origin's certificate is expired, self-signed, for another name or missing its intermediate, and the SSL mode is Full (strict).
• The fix: install a Cloudflare Origin CA certificate (free, up to 15 years) or a Let's Encrypt certificate on the origin, then set SSL/TLS encryption mode to Full (strict).
• Don't switch to Flexible to make the error go away. The connection to your server is then unencrypted.
• Test the origin directly with curl --resolve, then run the SSL checker on the public address.

Two connections, two certificates

With Cloudflare's proxy on (the orange cloud in DNS), every request crosses two connections:

1. Visitor to Cloudflare. Cloudflare presents its own edge certificate, issued and renewed automatically. This is the certificate visitors and checkers see.
2. Cloudflare to your origin. Cloudflare connects to your server's IP address, sending your host name in SNI, and, depending on the SSL mode, checks your server's certificate.

Errors 525 and 526 are both about the second connection. The SSL mode, under SSL/TLS → Overview in the Cloudflare dashboard, decides what Cloudflare does on it:

Cloudflare's Automatic SSL/TLS setting picks the most secure mode your origin supports and never lowers a setting you chose. If you set the mode by hand, you own the consequences.

If you're a visitor

A Cloudflare 525 or 526 page shows three boxes: "You", "Cloudflare" and the host, with the host marked as the error. That diagram is accurate: your browser and your connection work. Clearing the cache or changing browsers will not help. Try again in a few minutes, and if the site stays down, let its owner know the error code and the Ray ID at the bottom of the page.

Error 525: SSL handshake failed

Cloudflare opened a connection to your origin on port 443 and could not complete TLS. Cloudflare's documentation lists four causes:

• No valid certificate is installed for this host name on the origin, so the server has nothing to present, or rejects the name.
• Port 443 is not open, or it answers in plain HTTP. In nginx, listen 443; without ssl is a common slip.
• The origin does not support SNI, so it cannot choose the right certificate. Only very old servers lack it.
• No cipher suite in common between Cloudflare and the origin, usually after someone pasted a restrictive or ancient cipher list.

Full mode does not check the certificate's validity, so under Full a 525 always means the handshake itself broke, not that the certificate is untrusted. The same server problems show as ERR_SSL_PROTOCOL_ERROR to anyone who reaches the origin directly.

Two more causes are common in practice. A firewall or security plugin that blocks Cloudflare's IP ranges can reset connections mid-handshake; allow the ranges published at cloudflare.com/ips. A server that has just been moved often has a certificate for the old name only.

Error 526: invalid SSL certificate

With Full (strict), Cloudflare validates your origin certificate like a browser would. Cloudflare's documentation lists the requirements:

• Not expired and not revoked.
• Signed by a certificate authority, not self-signed. A Cloudflare Origin CA certificate counts, because Cloudflare trusts its own CA.
• The requested host name is in the certificate's Common Name or Subject Alternative Name list.
• The chain is complete, with the intermediate certificates included.

The usual story is an origin certificate that expired quietly: nobody sees it, because visitors get Cloudflare's valid edge certificate, until the mode is set to Full (strict) or a renewal fails. Another is a certificate for example.com while Cloudflare connects with www.example.com.

Find which part is broken

First, confirm the public side works. Cloudflare's edge certificate should always be valid:

The SSL checker sees what visitors see, so behind Cloudflare it reads Cloudflare's edge certificate, not your origin's. During a 525 or 526, the result shows the HTTP status (525 or 526) and no score, because an error page says nothing about your site. That tells you the edge is answering and the problem is between Cloudflare and your server. Once the origin is fixed, run it again to confirm the page loads and these findings pass:

Then test the origin directly, bypassing Cloudflare. Replace 203.0.113.10 with your server's IP address:

curl -v --resolve example.com:443:203.0.113.10 https://example.com/ -o /dev/null
openssl s_client -connect 203.0.113.10:443 -servername example.com </dev/null

• Connection refused or a timeout: nothing listens on 443, or a firewall blocks it. Open the port and allow Cloudflare's IP ranges.
• wrong version number: port 443 serves plain HTTP. Add TLS to that server block.
• A certificate appears: read its names and dates. With an Origin CA certificate, curl reports it as untrusted; that is expected, since only Cloudflare trusts it. With any other certificate, Verify return code: 0 (ok) means it will pass Full (strict).

Cloudflare's Origin Analytics also shows origin responses with status 0, which point to failed TLS negotiation, and your web server's error log names the reason at the same timestamps.

Fix it: a valid certificate and Full (strict)

Option 1: a Cloudflare Origin CA certificate

The simplest fix for a site that is only ever reached through Cloudflare's proxy.

1. In the Cloudflare dashboard, go to SSL/TLS → Origin Server → Create Certificate.

2. Keep "Generate private key and CSR with Cloudflare", list the host names (example.com and *.example.com cover most sites), and choose a validity of up to 15 years.

3. Copy the certificate and the private key into two files on the server. Cloudflare shows the private key only once.

4. Point the web server at them and reload:

   server {
       listen 443 ssl;
       listen [::]:443 ssl;
       server_name example.com www.example.com;
       ssl_certificate     /etc/ssl/cloudflare/example.com.pem;
       ssl_certificate_key /etc/ssl/cloudflare/example.com.key;
       ssl_protocols TLSv1.2 TLSv1.3;
   }

   Apache uses SSLCertificateFile and SSLCertificateKeyFile in the *:443 virtual host.

5. Set SSL/TLS → Overview to Full (strict).

The catch: browsers do not trust Origin CA certificates. If you ever turn the proxy off (grey cloud), visitors get “Your connection is not private”. Use option 2 if the server must also work without Cloudflare.

Option 2: a publicly trusted certificate on the origin

A Let's Encrypt certificate on the origin works with Full (strict) and without Cloudflare. It renews every few weeks, so renewal must work through Cloudflare: HTTP-01 validation reaches your server through the proxy as long as /.well-known/acme-challenge/ is not blocked, and DNS-01 with Cloudflare's API works regardless. Setup is in getting a free certificate with Let's Encrypt.

Whichever you choose, check the origin's certificate expiry now and then: Cloudflare will not warn you, and the first sign of a lapse is a 526 for everyone.

Why not Flexible or Full?

Flexible "fixes" a 525 by not using TLS to your origin at all. Visitors see a padlock, but the request travels to your server as plain HTTP across the internet, including form data and logins. It also causes redirect loops (ERR_TOO_MANY_REDIRECTS) when the origin redirects HTTP to HTTPS, because every request arrives over HTTP.

Full encrypts but accepts any certificate, so anyone who can intercept traffic between Cloudflare and your server can present their own. It is a step on the way, not a place to stay. The rest of the free-plan settings, including Always Use HTTPS and the minimum TLS version, are in Cloudflare settings for speed and security.

Verify

1. curl --resolve to the origin shows your certificate with the right names and future dates.
2. The SSL/TLS encryption mode reads Full (strict).
3. The site loads in a private window, and the SSL checker shows the page with a score, the HTTPS finding passed and one redirect from http://.
4. Every proxied host name loads: www, subdomains, and any API host behind the same zone.

Common mistakes

• Switching to Flexible to clear the error. The error goes, the encryption to your server goes with it.
• Setting Full (strict) before the origin has a valid certificate. Every page becomes a 526.
• An Origin CA certificate on a server you later un-proxy. Browsers do not trust it.
• Blocking Cloudflare's IP ranges in a firewall or security plugin, which shows up as 521, 522 or 525.
• Forgetting the origin certificate exists. It expires without anyone seeing it until Full (strict) turns it into an outage.

Questions people ask

How do I fix error code 525 SSL handshake failed?

Make your origin server complete a TLS handshake for the host name on port 443. Install a certificate for that name (a free Cloudflare Origin CA certificate is simplest), make sure the server block listens with TLS, open port 443 to Cloudflare's IP ranges, and remove any unusual cipher list. Test the origin with curl --resolve, then set the SSL mode to Full (strict). Switching to Flexible hides the error but drops encryption to your server.

What does error code 526 invalid SSL certificate mean?

It means Cloudflare reached your server but rejected its certificate while the SSL mode is Full (strict). The certificate is expired, revoked, self-signed, missing its intermediate, or does not cover the host name. Install a Cloudflare Origin CA certificate or a publicly trusted one such as Let's Encrypt, then reload the server. Downgrading to Full makes the error disappear but stops Cloudflare from checking who it is talking to.

Should I use Full or Full (strict) in Cloudflare?

Use Full (strict). It encrypts the connection to your server and checks that the server's certificate is valid for your domain, so nobody in between can impersonate it. Full also encrypts but accepts any certificate, including self-signed or expired ones. With a free Origin CA certificate valid for up to 15 years on your server, Full (strict) costs nothing and needs almost no maintenance.

Is a Cloudflare Origin CA certificate trusted by browsers?

No. It is trusted only by Cloudflare, so it is meant for the connection between Cloudflare and your server while the proxy is on. If visitors reach the server directly, for example after you switch the DNS record to DNS only, browsers show a certificate warning. For a server that must also work without Cloudflare, use a publicly trusted certificate such as Let's Encrypt instead.

Why did error 525 start suddenly when nothing changed?

Usually something did change on the server: a certificate renewal failed or wrote a broken file, a control panel or security update rewrote the TLS configuration, a firewall started blocking Cloudflare's IP ranges, or the site moved and the new server lacks a certificate for this host name. Check the web server's error log at the times of the failures, then test the origin directly with openssl s_client.