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
notAfterin the past? - Names: does the
subjectAltNamelist include the exact hostname that fails, such aswww.example.com, or a wildcard that matches it? A certificate forexample.comalone does not coverwww. - 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 और SSL Chain Debugger report expiry, names and missing intermediates from the outside.
Step 2: fix the specific problem
| Finding | Fix |
|---|---|
| Expired | Renew and reload the web server. See Let's Encrypt renewal failures. |
| Hostname not covered | Reissue with every hostname in the SAN list. |
| Self-signed | Install a CA-signed or Cloudflare Origin CA certificate, or add the certificate to the Custom Origin Trust Store. |
| Missing intermediate | Serve the full chain file (fullchain.pem), not only the leaf certificate. |
| Wrong virtual host | Make sure the correct certificate is bound to the hostname on port 443. |
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_fetchcompatibility flag.
Prevent the next one
Certificates expire silently. Automate renewal, and monitor expiry from the outside. The free अपटाइम मॉनिटर can alert on SSL expiry, and the Bulk SSL Checker helps if you manage many hostnames. The TLS वर्शन चेकर confirms the server also supports current protocols.
अगले कदम
- 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.
सामान्य प्रश्न
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.
Get notified when this fix updates
Plus occasional practical tips on uptime and monitoring, nothing else. Unsubscribe anytime.
यह पेज सामान्य जानकारी है, जिसे हमारी संपादकीय टीम ने लिखा है और दस्तावेज़ीकरण बदलने पर अपडेट किया जाता है। सर्वर और प्रदाता अलग-अलग होते हैं, इसलिए बदलाव पहले सुरक्षित तरीके से जाँचें। देखें: संपादकीय नीति और अस्वीकरण.