Cloudflare Error 526: Invalid SSL Certificate (Full Strict Fix)

Error 526 means Cloudflare could not validate the SSL certificate on your origin server. Cloudflare's documentation says it appears when two conditions hold: Cloudflare cannot validate the origin certificate, and the domain's SSL/TLS mode is Full (strict). In that mode, Cloudflare insists the origin presents a certificate that is valid and trusted.

Compare this with error 525, where the handshake never completes. With a 526 the handshake works and the certificate is the problem. For the overview of every 52x code, see Cloudflare 520-526 errors explained.

The visitor sees a Cloudflare page headed "Invalid SSL certificate." The visitor's connection to Cloudflare is secure; the failure is between Cloudflare and the origin.

What Cloudflare checks

Cloudflare's docs list what to verify about the origin certificate. It must:

• Not be expired or revoked.
• Be signed by a Certificate Authority rather than self-signed (unless you add it to the Custom Origin Trust Store).
• Cover your hostname in its Common Name or Subject Alternative Name.
• Include the full chain, including intermediate CA certificates.
• Be served on port 443.

Any one of these failing causes a 526 in Full (strict).

If you are a visitor

You cannot fix this from your device. Wait and retry, then report it to the site owner with the Ray ID. Do not try to bypass it by using a different "unprotected" URL for the same site.

If you are the site owner

Step 1: inspect the certificate the origin actually presents

Query the origin IP directly with your hostname as SNI, and print the subject, issuer, names and dates:

echo | openssl s_client -connect ORIGIN_IP:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates -ext subjectAltName

Check each item:

• Dates: is notAfter in the past?
• Names: does the subjectAltName list include the exact hostname that fails, such as www.example.com, or a wildcard that matches it? A certificate for example.com alone does not cover www.
• Issuer: if the issuer equals the subject, it is self-signed.

Cloudflare's docs suggest temporarily pausing Cloudflare and running the hostname through an SSL checker. The SSL Checker and SSL Chain Debugger report expiry, names and missing intermediates from the outside.

Step 2: fix the specific problem

Remember to reload after changing files: sudo nginx -t && sudo systemctl reload nginx. A renewed certificate on disk that the running server has not reloaded still serves the old one. Verify with the openssl s_client command again.

Step 3: use a Cloudflare Origin CA certificate

For an origin that only Cloudflare will talk to, you can create a free Origin CA certificate in the Cloudflare dashboard and install it, as Cloudflare's documentation suggests. Browsers do not trust these, so use it only if all traffic goes through the proxy. If you ever turn the proxy off for a hostname, visitors will see certificate warnings there.

Step 4: quick workaround, with a caveat

Cloudflare's documented quick workaround is to change the mode from Full (strict) to Full. Full still encrypts to the origin but does not validate the certificate, so an attacker on the path could impersonate your origin. Use it as a short bridge while you fix the certificate, then return to strict. See Cloudflare DNS and SSL modes.

Step 5: handle self-signed certificates properly

If you must keep a self-signed certificate, add it to the Custom Origin Trust Store in Cloudflare so it is accepted under strict validation, per the docs. This is better than dropping to Full because validation still happens.

Special cases from Cloudflare's docs

• Cloudflare Gateway (Zero Trust): Gateway also returns 526 when the origin certificate is untrusted (unknown or untrusted issuer, revoked, an expired certificate in the chain, a Common Name mismatch or invalid characters such as underscores) or when the connection to the origin is insecure (weak ciphers such as RC4 or 3DES, no FIPS-compliant ciphers when FIPS mode is on, or HTTPS redirected to HTTP).
• Workers: subrequests to external hostnames outside your zone that are not proxied through Cloudflare always use Full (strict), regardless of your zone setting. Fix the origin certificate, add a self-signed certificate to the Custom Origin Trust Store, or use the cots_on_external_fetch compatibility flag.

Prevent the next one

Certificates expire silently. Automate renewal, and monitor expiry from the outside. The free Uptime Monitor can alert on SSL expiry, and the Bulk SSL Checker helps if you manage many hostnames. The TLS Version Checker confirms the server also supports current protocols.

Next steps

• Verify the certificate on your hostname with the SSL Checker.
• Find chain problems using the SSL Chain Debugger.
• Read SSL certificate types explained to choose the right origin certificate.
• Automate renewals following how to renew an SSL certificate.
• Compare with error 525 if the handshake itself fails.

FAQ

Why did 526 start although the certificate looked fine in the browser?

The browser sees Cloudflare's edge certificate, not your origin's. The origin certificate may be expired or mismatched while the edge certificate is valid.

Is Full instead of Full (strict) safe?

It encrypts the connection but does not verify the origin certificate, so it is weaker. Use it only briefly while repairing the certificate.

Does Let's Encrypt work as an origin certificate?

Yes, any publicly trusted CA certificate that covers the hostname and is served with its full chain should pass Full (strict).

Do I need the full chain on the origin?

Yes. Cloudflare's docs list the full chain, including intermediates, among the requirements.

This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.