Why Am I Getting Cloudflare Error 525: SSL Handshake Failed?

The full wording on the page is error 525: SSL handshake failed, and “Cloudflare 525”, “error code 525” and “CF error 525” all refer to the same thing. It is worth being precise about where it sits, because the neighbouring codes have completely different fixes: the TCP connection to your origin already succeeded. Something answered on the port. What failed is the negotiation that happens immediately afterwards, before a single byte of HTTP is exchanged.

Two conditions, and one of them surprises people

Cloudflare’s reference for this error states that it occurs when two things are true at once: the SSL handshake between Cloudflare and the origin fails, and the encryption mode is Full or Full (strict).

That second condition is the one that trips people up, because it is an or, not an and. A great deal of advice about this code assumes 525 is a strictness problem and tells you to step down from Full (strict) to Full. That is the documented quick fix for a 526, and it does nothing here. Cloudflare’s own page for Full mode says the opposite in its prerequisites: make sure the origin allows HTTPS connections on port 443 and presents a certificate, otherwise visitors may see a 525.

There is one genuine subtlety in Full mode worth knowing before you go hunting. Cloudflare documents Full as connecting to the origin using the scheme the visitor requested — an HTTP visitor gets a plaintext connection to your origin, an HTTPS visitor gets a TLS one. So on a Full-mode zone a 525 can only ever appear on HTTPS requests, which is why the error sometimes looks intermittent when the real pattern is that only some of your traffic is negotiating TLS at all.

Where in the handshake it dies

Four conditions have to hold for the handshake to finish. Cloudflare lists all four as the common causes to exclude at the origin, and any single one of them failing produces the same page.

Reading the diagram left to right through the failure modes gives you a working checklist:

• No valid certificate is installed. The most common cause by a distance, and it includes the case where a certificate exists for a different hostname or was never loaded by the running web server process.
• Port 443 is not open. Or the custom secure port you configured is not. Note that a firewall which drops the packet produces a 522 instead, because that failure happens before TLS begins.
• The origin does not support SNI. Cloudflare sends the hostname in the ClientHello and expects the origin to select a certificate from it. A server on a shared address with no SNI handling cannot answer that.
• No cipher suite in common. The subtle one, covered below.

Cloudflare also flags a cause that sits outside all four: a hosting provider that changes your origin IP address without telling you. Your DNS record then points at a machine that never had a certificate for your hostname, and a site nobody touched starts failing.

525 against its neighbours

The 52x codes each name a different layer of the same journey, and knowing which layer you are on eliminates most of the search space before you open a single config file.

The 525/526 boundary is the one worth internalising. A 526 requires that a certificate actually arrived, which is why it only exists under Full (strict) — that is the only mode that validates anything. If you are getting a 525, Cloudflare never got far enough to have an opinion about your certificate.

The cipher mismatch nobody expects

This is the cause that survives every obvious check: a valid certificate is installed, port 443 is open, SNI works, and the handshake still fails. Cloudflare publishes the exact cipher suites it offers origins, and it is a separate list from the one it presents to browsers and other user agents.

The trap is that hardening guides for web servers are written with browsers in mind. An origin locked down to a modern, TLS 1.2-and-ChaCha20-only policy can end up with no overlap at all, because Cloudflare’s origin-facing TLS 1.2 rows are the ECDHE and legacy AES suites — ChaCha20 appears only in the TLS 1.3 section. Tighten the origin past what Cloudflare offers and the negotiation has nothing to agree on. That same page publishes an NGINX ssl_ciphers line for origins that want to match what Cloudflare supports, which is the quickest way out of this one.

Confirming it yourself

Testing through Cloudflare tells you nothing, because you will be talking to Cloudflare rather than to your origin. You need to speak TLS to the origin address directly, with the hostname supplied as SNI — which tests all four conditions in one command:

openssl s_client -connect ORIGIN_IP:443 -servername example.com

A certificate chain and a negotiated cipher in the output means the handshake works and your 525 is coming from somewhere else. A refusal, an empty certificate section or a handshake failure reproduces the error at the exact layer Cloudflare hit. Cloudflare’s own troubleshooting guidance points at curl for the same purpose.

Two more places carry the answer when the failure is intermittent. Your origin’s error log is the authoritative one: nginx includes SSL errors in its standard error log though it may need the log level raised, and Apache has to be configured to log mod_ssl errors before it says anything useful. On the Cloudflare side, Origin Analytics records an origin response status of 0 when no HTTP response came back at all, which is what a failed TLS negotiation looks like from the edge. Cross-referencing those timestamps against the origin log is the fastest way to catch a handshake that only fails under load.

Fixing it

Every documented cause lives at the origin, so this is a list of things to change on your server, in the order that resolves the most cases:

1. Install a certificate. If the origin has none, a free Cloudflare Origin CA certificate is the path Cloudflare recommends. It is trusted for Cloudflare-to-origin traffic specifically, which is all this hop needs.
2. Open port 443 to Cloudflare, and confirm the web server is actually listening on it rather than only on port 80.
3. Widen the cipher and protocol list until it overlaps what Cloudflare offers origins, using the published list as the reference rather than guessing.
4. Check SNI handling if the origin serves several hostnames from one address.

One thing not to do: switching to Flexible. It will make the error disappear, because Cloudflare stops speaking TLS to your origin entirely — which means that hop travels in plaintext across the public internet, and it commonly produces redirect loops as a parting gift. If you are weighing that trade, the encryption modes are worth understanding before you change one. A certificate that fails validation but still encrypts is a far better position than no encryption at all, and if that is where you are, Full or the Custom Origin Trust Store both beat Flexible.

FAQ