Error 525 and 526 behind Cloudflare: what they mean and how to fix them
Both errors mean Cloudflare reached your server and could not trust its HTTPS. How to tell which one you have and fix it at the origin.
What the two numbers mean
With the orange cloud on, a visitor talks to Cloudflare and Cloudflare talks to your server, the origin. Both errors are about that second connection.
525, SSL handshake failed. Cloudflare connected to the origin on port 443 and the TLS handshake did not complete. The usual reason is that the origin has no certificate to offer for that name.
526, invalid SSL certificate. The handshake completed, but Cloudflare's SSL mode is Full (strict) and the certificate did not pass: it is expired, self-signed, or issued for a different name.
Neither error means the site is down. Plain HTTP usually still reaches the origin. That is good news, because it means the fix is a certificate and not a rebuild.
Look at what the origin really offers
Skip Cloudflare and ask the origin directly. Replace the address with your server's own:
curl -sv -o /dev/null --resolve example.com:443:203.0.113.10 https://example.com/Read the lines about the certificate. Three outcomes cover nearly every case:
- The handshake fails. No certificate for this name. That is your 525.
- The subject is another domain. The server answered with a different site's certificate. Under Full (strict) that is a 526.
- The expiry date has passed. Renewal stopped working some time ago. Also a 526.
The fix: a real certificate at the origin
The durable fix is the same for both errors: give the origin a valid certificate for the exact names Cloudflare asks for, including www if you use it.
There are two kinds that work. A publicly trusted certificate, such as one from Let's Encrypt, works in every Cloudflare mode and still works on the day you turn the proxy off. A Cloudflare Origin CA certificate is trusted by Cloudflare only, so visitors get a warning the moment the proxy is off.
People often turn the proxy off to get a Let's Encrypt certificate and turn it back on afterwards. That works, and it exposes the origin address while you do it. Whether you can avoid it depends on your panel.
Why Flexible is a stopgap, not a fix
Switching Cloudflare's SSL mode to Flexible makes both errors disappear at once, because Cloudflare stops using HTTPS to reach the origin. Two things come with that. The traffic between Cloudflare and your server is unencrypted. And if the origin redirects HTTP to HTTPS, the visitor gets a redirect loop instead of a page.
Use it to get a site back while the certificate is issued, then return to Full (strict).
What KLYRN does about it
Three changes in KLYRN 1.0.2 are about exactly this.
A domain behind Cloudflare with the proxy on gets its certificate without turning the proxy off. KLYRN checks whether a request for the name arrives at the server, not what the DNS record says.
A site with no certificate is no longer answered over HTTPS by another site on the server. The request is refused at the handshake until the site has its own certificate. The alternative is a visitor being shown a certificate, and possibly a page, that belongs to somebody else.
And the site diagnosis checks the public address as well as the server:
klyrn site diagnose example.com
klyrn site ssl example.comWhen Cloudflare reaches the server and HTTPS between them fails, the diagnosis says so in those words: visitors get the Cloudflare error although Cloudflare does reach this server. Its advice is to issue the certificate from the site's SSL tab, which works through the proxy, and it names Flexible as what serves the site until the certificate exists.
If the certificate still does not arrive, klyrn dns check example.com prints what the name resolves to and what the server's own address is, side by side.