526 Invalid SSL Certificate

Full (strict) makes Cloudflare check the origin certificate the way a browser would. Cloudflare’s checklist: not expired, not revoked, signed by a certificate authority (or a Cloudflare Origin CA certificate), the requested hostname in the Common Name or Subject Alternative Name, and a complete chain with the intermediates the origin must send along with the leaf.

Visitors never see the origin certificate, so an expired one can go unnoticed until the day Cloudflare starts rejecting it. Monitoring expiry on the origin, not just on the public edge certificate, prevents most 526s.

If you are visiting the site

• The site’s server has a certificate problem that Cloudflare refuses to accept. The padlock in your browser refers to Cloudflare’s certificate, which is fine.

If you run the server

• The origin certificate expired because certbot or another renewal job failed, often after the site moved behind Cloudflare and HTTP validation stopped reaching the server.
• A self-signed certificate, which Full (strict) rejects unless added to the Custom Origin Trust Store.
• The certificate covers example.com but not www.example.com, or covers an old hostname.
• The server sends only the leaf certificate without the intermediate chain.

If you are visiting the site

• Tell the site owner; there is nothing you can change in your browser to get past it.

If you run the server

• Inspect the origin certificate dates, names and chain with openssl (below) against the origin IP, not through Cloudflare.
• Renew or replace it. A Cloudflare Origin CA certificate avoids renewal problems for origins that only receive Cloudflare traffic.
• Serve the full chain: in nginx, ssl_certificate should point to fullchain.pem, not cert.pem.
• Only as a temporary measure, switch the zone from Full (strict) to Full, which skips validation, then switch back once the certificate is fixed.

Cloudflare generates this code at its edge when it cannot get a usable answer from your origin; your server never sends it. The commands below talk to the origin directly, skipping Cloudflare, so you can see what Cloudflare sees.

# Dates, names and issuer of the certificate the origin serves
openssl s_client -connect ORIGIN_IP:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

# Does the origin send the intermediate chain? Count the certificates
openssl s_client -connect ORIGIN_IP:443 -servername example.com -showcerts </dev/null 2>/dev/null \
  | grep -c 'BEGIN CERTIFICATE'

526 vs 525

With 525 the TLS handshake itself failed; with 526 it completed and the certificate the origin presented did not pass validation.

What is the fastest way to fix error 526?

Switching the SSL/TLS mode from Full (strict) to Full removes the error immediately because Full does not validate the origin certificate. Treat it as temporary and fix the certificate.

Can I use a self-signed certificate with Full (strict)?

Only if you upload it to Cloudflare’s Custom Origin Trust Store. Otherwise use a Cloudflare Origin CA certificate or one from a public certificate authority.

Why do I get 526 from a Cloudflare Worker?

Worker subrequests to hostnames outside your zone that are not proxied by Cloudflare always use Full (strict), whatever your zone setting, so that external host needs a valid certificate.

My certificate is valid in the browser. Why does Cloudflare say 526?

The browser checks Cloudflare’s edge certificate, not your origin’s. Test the origin directly with openssl s_client against its IP to see the certificate Cloudflare actually receives.