Fix Cloudflare Error 526 on a Coolify App Without Weakening TLS

A Cloudflare 526 Invalid SSL certificate error often appears during a custom-domain move: DNS now sends visitors toward the new VPS, Cloudflare can reach port 443, but Coolify’s Traefik proxy is still serving a default, expired, untrusted, or wrong-host certificate.

The tempting fix is to turn off strict certificate validation and move on. That may hide the symptom, but it removes the proof that Cloudflare is talking to the intended origin. A better fix is to separate the three systems involved—Cloudflare’s edge certificate, the origin certificate, and Coolify’s hostname routing—and verify each one.

A 526 is usually not an edge-certificate problem. Cloudflare accepted the browser connection, then rejected the certificate presented by the origin.

What Cloudflare 526 actually means

Cloudflare’s 526 documentation says the error occurs when the zone uses Full (strict) and Cloudflare cannot validate the origin certificate. Its Full (strict) requirements include an unexpired certificate from a publicly trusted CA or Cloudflare Origin CA, a matching hostname, and HTTPS availability on port 443.

This is different from a 525, where the TLS handshake itself fails. With a 526, the useful question is: which certificate does the origin present for this exact hostname?

1. Stop and preserve the last known-good route

If this is a live hostname migration, write down the old DNS target before changing anything. Do not delete the old application or origin while diagnosing the new one. A quick rollback is safer than stacking speculative DNS, proxy, and TLS changes.

Also check that the hostname was added to the intended Coolify application before the DNS cutover. Traefik selects routers and certificates using the requested hostname; a healthy container without a matching domain can still produce a default certificate or a 404.

2. Confirm public DNS points where you think it does

dig +short A app.example.com
      dig +short AAAA app.example.com
      dig +short CNAME app.example.com

Check all record types, not only the A record. A stale AAAA record can send some validation requests and visitors to an old IPv6 origin. A leftover CNAME can produce the same split behaviour. Compare the answer with your intended destination privately; never publish a real origin address in a troubleshooting post or ticket.

3. Give Let’s Encrypt a reachable validation path

For a normal public Coolify application, the least surprising cutover is often:

1. Add the final hostname to the Coolify application.
2. Make sure inbound ports 80 and 443 reach Coolify’s proxy.
3. Temporarily set that web DNS record to DNS only.
4. Deploy or restart the proxy/app so certificate issuance runs.
5. Wait for a valid certificate for the exact hostname.
6. Verify the certificate directly, then restore the Cloudflare proxy.

Let’s Encrypt documents that HTTP-01 validation starts on port 80. Coolify’s own Let’s Encrypt troubleshooting guide likewise calls out ports 80/443, correct DNS, and Cloudflare proxy settings. If your firewall blocks port 80, HTTP-01 issuance cannot be rescued by opening a random alternative port.

DNS-only mode is a temporary issuance and diagnosis step, not a reason to leave an origin exposed indefinitely. If your architecture deliberately uses Cloudflare Tunnel or DNS-01 validation, follow that architecture’s certificate path instead of mixing it with HTTP-01 advice.

4. Inspect the origin certificate with SNI

A generic request to the server’s address is not enough. TLS virtual hosting depends on Server Name Indication, so test with the real hostname while privately directing the connection to the intended origin:

openssl s_client \
        -connect ORIGIN_IP_HERE:443 \
        -servername app.example.com \
        -verify_hostname app.example.com \
        -showcerts </dev/null

Look for a successful verification result, a validity period covering the current date, and a Subject Alternative Name containing app.example.com. Do not paste the full output into public reports without reviewing it first.

You can also prove the HTTP route while bypassing public DNS:

curl --resolve app.example.com:443:ORIGIN_IP_HERE \
        -I https://app.example.com/health

A certificate-name error means issuance or SNI routing is still wrong. A valid certificate plus a Traefik 404 suggests the hostname does not match a router. A 502 or 503 usually moves the investigation behind Traefik, toward the application port, network, or health state.

5. Check Coolify and Traefik, not just the container

In Coolify, verify the application’s domain list, deployment status, exposed port, and health check. Then inspect proxy logs around the certificate request. Useful failure classes include:

• DNS resolves to a different server than the one requesting the certificate.
• Port 80 or 443 is blocked or occupied by another proxy.
• The hostname is missing from the application’s domains.
• A restrictive CAA record does not allow the chosen certificate authority.
• Rate limits were reached after repeated retries.
• The certificate exists, but Traefik has not loaded it for this router.

If you recently tightened CAA records, use the checks in my CAA guide for Coolify and Cloudflare. Do not keep hammering redeploy while the same DNS or firewall prerequisite remains broken.

6. Re-enable Cloudflare only after direct origin proof

Once direct SNI verification succeeds, turn the Cloudflare proxy back on and keep the zone at Full (strict). Then test the public path from a clean client:

curl -sS -o /dev/null -w '%{http_code}\n' https://app.example.com/
      curl -I https://app.example.com/health

Expect the application’s normal status and confirm that any canonical redirect lands on the intended HTTPS hostname. If Cloudflare still returns 526 after the origin test passes, allow for DNS propagation, confirm Cloudflare now resolves the intended origin, and re-check that the hostname tested is exactly the hostname requested by visitors.

Should you switch from Full (strict) to Full?

Cloudflare lists Full as a possible temporary workaround because it encrypts the origin connection without validating the origin certificate. That can restore availability during an incident, but it should be time-bounded and paired with a rollback plan. It is not the completed fix.

Never use Flexible for this pattern. Flexible mode leaves the Cloudflare-to-origin leg on HTTP and can create redirect loops when the application expects HTTPS.

A safe 526 recovery checklist

1. Preserve the previous DNS target and rollback option.
2. Add the exact hostname to the correct Coolify application.
3. Check A, AAAA, CNAME, CAA, and inbound ports 80/443.
4. Use DNS-only mode temporarily when HTTP-01 needs direct reachability.
5. Inspect the origin certificate with SNI and hostname verification.
6. Prove Traefik routes the hostname to a healthy application.
7. Re-enable Cloudflare proxying and retain Full (strict).
8. Verify the public page, redirects, health endpoint, and certificate path.

The core lesson is sequencing. Configure the Coolify hostname first, make validation reachable, prove the origin certificate, and only then put the strict Cloudflare proxy path back in front. That turns a vague 526 page into a small set of testable conditions without permanently weakening TLS.