Dotted pixel art of a pale road curving along a brown hillside beside a teal lake.

Fixing Cloudflare error 526

Author
gunlaug team
Updated
8 Nov 2026
Reading time
8 min

Photo by Gaetan THURIN

Cloudflare returns 526 when your server’s certificate fails validation under Full (strict). You can find the failing check with openssl, and on Traefik or Coolify the fix depends on how the certificate is issued.

What Full (strict) checks

Cloudflare’s Full (strict) page sets three conditions on the certificate your origin presents. If one fails, visitors may see a 526.

  • The current time falls between its not-before and not-after dates.
  • It was issued by a publicly trusted authority or by Cloudflare’s own Origin CA.
  • Its Common Name or Subject Alternative Name matches the requested hostname.

The error 526 page adds that the certificate must not be revoked, that the server must send the leaf with any intermediates so Cloudflare can build a chain, and that the origin must accept HTTPS on port 443.

How each Cloudflare encryption mode connects to the origin
ModeCloudflare to originCertificate check
FlexibleAlways HTTPNone, no certificate needed
FullSame scheme as the visitorNot validated
Full (strict)Same scheme as the visitorDates, issuer and hostname

Only the last row can return a 526. A failed TLS handshake is a 525, and a timeout reaching the server is a 522, which has its own causes on Coolify.

Find the failing check

1. Confirm the mode and the records

In the Cloudflare dashboard, open SSL/TLS, then Overview, and confirm the zone is on Full (strict). Check that the A and AAAA records on the DNS page point at this server. Automatic SSL/TLS will not lower a zone to Full when an origin certificate expires, so the 526 stays until the certificate is fixed.

2. Read the certificate the server presents

Run this on the origin itself, so a firewall that only allows port 443 from Cloudflare can’t block the test. Use the hostname that returns the error.

openssl s_client -connect 127.0.0.1:443 \
  -servername www.example.com \
  -verify_hostname www.example.com </dev/null

-servername sets the SNI value, and Traefik picks its certificate from SNI. With no SNI or no match, it falls back to its default certificate. OpenSSL fills in SNI from -connect only when that value is a DNS name, so a test against an IP address sends none and shows you the fallback.

The Cloudflare pages listed below don’t state which SNI value goes out on an ordinary proxied request. Its Origin Rules page says a Host header override also updates SNI, so test the public hostname unless you have a rule like that, and test the rule’s value if you do.

3. Print the fields Cloudflare looks at

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

From another machine, the curl form Cloudflare documents skips the proxy and shows the origin certificate. Replace the address with your server’s.

curl -svo /dev/null https://www.example.com \
  --connect-to ::203.0.113.34

4. Match the output to a cause

  • Subject and issuer read TRAEFIK DEFAULT CERT. That is Traefik’s generated self-signed certificate, so issuance failed or never ran. The next section explains why.
  • certificate has expired means renewal stopped. Traefik starts renewing 90-day certificates 30 days before expiry, so the first 526 can come about a month after renewals began to fail.
  • hostname mismatch means the name is missing from the certificate. Origin CA wildcards cover one level only.
  • unable to verify the first certificate or unable to get local issuer certificate on a public certificate points to a missing intermediate. An Origin CA certificate can show the same OpenSSL errors, because its CA isn’t in public trust stores. For those, confirm the issuer says CloudFlare Origin SSL Certificate Authority and that the dates are current.
  • self-signed certificate on a file you generated yourself means replacing it with an Origin CA or public certificate.
  • Verify return code: 0 (ok) means this server passes. Go back to step 1, since Cloudflare may be connecting to a different machine.
Dotted pixel art of a rose pink sky above a dark teal swell of water.Photo by Keith Lobo

Why Let’s Encrypt fails here

Coolify’s default Traefik setup uses the HTTP challenge. Let’s Encrypt fetches a token from /.well-known/acme-challenge/ on port 80, the only port the standard allows. A proxied record answers DNS with Cloudflare’s anycast addresses, so that request lands on Cloudflare. What happens next depends on Always Use HTTPS.

With Always Use HTTPS off

Full (strict) does everything Full does, and Full connects to the origin with the visitor’s scheme. The plain HTTP request goes to port 80 on your server and Traefik answers it. A firewall rule at Cloudflare can still get in the way. Coolify says a 403 in the proxy logs points to a WAF blocking Let’s Encrypt.

With Always Use HTTPS on

Always Use HTTPS redirects visitor requests to https. Let’s Encrypt follows up to 10 redirects and ignores certificate errors on them, so it asks again over HTTPS. Cloudflare then opens HTTPS to the origin under Full (strict). A server with no valid certificate returns 526 at that point, so validation fails and no certificate gets issued.

A server that still has a valid certificate fails differently. The request reaches port 443, but Traefik attaches its ACME route to the challenge entrypoint only, and nothing on https serves the token. The old certificate keeps working until it expires, which Coolify describes as a domain that works for months and then fails.

This sequence is worked out from each vendor’s documentation. Cloudflare’s page says its own certificate validation is unaffected by the redirect and doesn’t mention other ACME clients, so confirm it against your proxy logs.

TLS-ALPN-01 and rate limits

The TLS-ALPN-01 challenge validates inside a TLS handshake on port 443, and on a proxied record the visitor’s connection ends at Cloudflare. Coolify’s advice covers both challenges: use a DNS challenge or stop proxying the domain.

Retries are limited. Let’s Encrypt allows 5 authorization failures per identifier, per account, per hour, refilling one every 12 minutes. Fix the challenge before you retry. Coolify’s reset, rm /data/coolify/proxy/acme.json, deletes every certificate Traefik has stored, so copy the file first.

Fix it on Coolify

Use a Cloudflare Origin CA certificate

Coolify recommends this when Cloudflare will always be in front of the site.

  1. In Cloudflare, open SSL/TLS, then Origin Server, and create a certificate for your hostnames.
  2. Save the certificate and key on the server as /data/coolify/proxy/certs/example.cert and example.key.
  3. In Coolify, open Server, Proxy, Dynamic Configuration, and add a file whose name ends in .yaml with the content below.
  4. Set the certificate resolver to None for those domains, so Traefik makes no certificate requests.
tls:
  certificates:
    - certFile: /traefik/certs/example.cert
      keyFile: /traefik/certs/example.key

No challenge runs in this setup, so Always Use HTTPS can stay on. Track the expiry date yourself, because Cloudflare sends no expiration notices for these certificates.

Or move Let’s Encrypt to the DNS challenge

DNS-01 proves control with a TXT record at _acme-challenge, so no request passes through the proxy. The result is a publicly trusted certificate that still works if you pause Cloudflare. In Servers, your server, Proxy, Configuration, remove the two httpchallenge flags and add these lines to the traefik service.

environment:
  - CF_DNS_API_TOKEN=<cloudflare-api-token>
command:
  - '--certificatesresolvers.letsencrypt.acme.dnschallenge.provider=cloudflare'
  - '--certificatesresolvers.letsencrypt.acme.dnschallenge.delaybeforecheck=0'

Limit the token to DNS edit on that zone. Restart the proxy, redeploy one resource with an HTTPS domain, and read the proxy logs for ACME messages. Then rerun the openssl command from step 2.

Setting the record to DNS only also lets the HTTP challenge reach your server, but you give up the proxy, and the renewal problem returns once you turn it back on with Always Use HTTPS enabled.

Why Flexible is the wrong fix

Flexible clears the 526 because Cloudflare then talks to your server over plain HTTP and checks nothing. Traffic between Cloudflare and the origin is unencrypted, the certificate is still broken, and Cloudflare says sites with logins or personal data should use Full or Full (strict).

On Coolify it can also take the site down. An origin that redirects HTTP to HTTPS under Flexible creates a redirect loop, and Coolify’s Traefik labels add that redirect when force HTTPS is on for a resource. The 526 then becomes ERR_TOO_MANY_REDIRECTS.

Cloudflare’s 526 page does list Full as a potential quick fix. Full doesn’t validate the certificate in any way, so the site comes back while you work, and Cloudflare warns that without Full (strict) “a malicious party could technically hijack the connection”. Switch back as soon as step 2 comes up clean.

Common questions

Why did the site work for months before the 526?

Traefik keeps serving a valid certificate while renewals fail. The error appears when that certificate expires, and Let’s Encrypt certificates last 90 days by default.

Do browsers trust a Cloudflare Origin CA certificate?

No. It only covers the connection between Cloudflare and your server, so visitors see certificate errors if you pause Cloudflare or set the record to DNS only.

Can Full (strict) accept a self-signed certificate?

Only through the Custom Origin Trust Store, which needs Advanced Certificate Manager on the zone. Origin CA certificates are available on every plan.

Sources

Where this comes from: the Cloudflare, Let’s Encrypt, Coolify, Traefik and OpenSSL documentation below, plus the Traefik and Coolify source files linked above, all read on 8 November 2026. The error was not reproduced on a server for this article, which was prepared with help from AI.