Fix Cloudflare Error 526: Invalid SSL Certificate

You turn on Cloudflare, flip SSL mode to "Full (strict)" because it's the secure option, and suddenly every visitor sees error 526: Invalid SSL Certificate. The site was working fine an hour ago. Nothing on the origin server changed. Here's what's actually happening and how to fix it without dropping back to a weaker SSL mode out of frustration.

Symptom: error 526 appears right after you tighten SSL mode

The pattern is almost always the same:

• Visitors get Cloudflare's own error page: "Invalid SSL certificate — Error 526"
• Loading the site directly by IP, bypassing Cloudflare, either fails outright or shows a browser SSL warning
• The error started right after you switched Cloudflare's SSL/TLS mode to Full (strict), added a new domain to Cloudflare, or renewed a certificate
• WHM/cPanel shows AutoSSL as "issued and active" — so it's tempting to assume the certificate is fine

This is different from error 525 (SSL handshake failed), which usually means there's no certificate at all or a protocol mismatch. 526 means Cloudflare found a certificate on your origin, but doesn't trust it.

Cause: Cloudflare's "Full (strict)" mode verifies the origin cert, not just its presence

Cloudflare has three main SSL/TLS modes for the connection between its edge servers and your origin:

Error 526 shows up specifically in Full (strict) mode when the certificate on your origin server fails one of these checks:

• It's self-signed or issued by a CA Cloudflare's edge doesn't recognize
• It expired, and AutoSSL or Let's Encrypt silently failed to renew it (common after a firewall change blocks the ACME HTTP-01 challenge)
• It's a valid cert, but for the wrong hostname — e.g. cPanel's default "webmail" or hostname cert is being served instead of the one for your actual domain
• The certificate chain is incomplete — the leaf cert is fine, but the intermediate certificate wasn't installed alongside it

WHM showing AutoSSL as "active" only means a certificate is installed for that domain — it doesn't tell you whether Cloudflare's edge, using its own trust store, considers it valid for that specific hostname.

Fix: give the origin a certificate Cloudflare actually trusts

Option 1: Install a Cloudflare Origin CA certificate (recommended)

This is the cleanest fix if the domain's traffic always goes through Cloudflare. It's a free certificate issued by Cloudflare itself, valid for up to 15 years, and Cloudflare's edge trusts it by definition.

1. In the Cloudflare dashboard: SSL/TLS → Origin Server → Create Certificate
2. Keep the default RSA key, list your domain and *.yourdomain.com, leave validity at 15 years
3. Copy the generated certificate and private key — Cloudflare only shows the private key once
4. In cPanel: SSL/TLS → Manage SSL sites → Install an SSL Website, pick the domain, and paste the certificate into the Certificate field and the key into the Private Key field
5. Click Install Certificate

Because this cert is only trusted by Cloudflare (not by browsers directly), make sure Cloudflare's proxy — the orange cloud — stays enabled on that DNS record. If it's set to "DNS only" (grey cloud), visitors hit the origin cert directly and will get a browser warning.

Option 2: Fix the existing AutoSSL / Let's Encrypt certificate

If you'd rather keep a publicly-trusted cert on the origin (useful if you sometimes bypass Cloudflare for testing), diagnose the actual problem first:

# Check what certificate the origin is actually serving, bypassing Cloudflare
openssl s_client -connect YOUR_SERVER_IP:443 -servername yourdomain.com < /dev/null 2>/dev/null | openssl x509 -noout -dates -subject -issuer

Look at three things in the output:

• subject — does the CN/SAN actually match your domain, not just the server hostname?
• issuer — is it Let's Encrypt / Sectigo / another public CA, not "self-signed"?
• notAfter — has it actually expired?

If it's expired or self-signed, force a fresh AutoSSL run in WHM: WHM → SSL/TLS → Manage AutoSSL → Run AutoSSL for the account. If that fails, check /usr/local/cpanel/logs/autossl.log for the exact rejection reason — it's almost always the domain's DNS pointing away from the server, or Cloudflare's proxy blocking the HTTP-01 validation request. Temporarily setting the DNS record to "DNS only" (grey cloud) during the AutoSSL run lets the validation request reach the origin directly, then switch it back to proxied afterward.

Option 3: Drop to Full (non-strict) as a stopgap only

If you need the site back up immediately while you sort out the certificate, Cloudflare dashboard → SSL/TLS → Overview → set the mode to Full. This removes the strict validation and the site will load again. Treat this as temporary — Full mode still encrypts traffic to the origin, but it won't catch a compromised or spoofed origin certificate. Set a reminder to switch back to Full (strict) once Option 1 or 2 is done.

Prevention: stop 526 from coming back after the next renewal

• Prefer the Cloudflare Origin CA certificate over AutoSSL for domains that are always proxied — it doesn't expire for 15 years and has one less moving part
• If you keep AutoSSL, monitor certificate expiry independently of WHM's own status page — a simple openssl s_client check in a cron job that alerts on age is enough
• Never leave a domain fully in "DNS only" (grey cloud) mode long-term if you're relying on Full (strict) — Cloudflare can't proxy or protect a hostname it isn't fronting
• After any firewall or CSF rule change on the VPS, re-run AutoSSL once to confirm the ACME challenge still reaches the server on port 80

Wrapping up

Error 526 is Cloudflare telling you it doesn't trust your origin's certificate — not that HTTPS is broken. In almost every case, installing a Cloudflare Origin CA certificate on the origin server is the fastest, most durable fix, since it removes the public-trust requirement entirely for a hostname that only ever talks to Cloudflare's edge.