How to check SSL certificates behind a CDN

Separate a healthy edge certificate from an origin failure

Suppose CheckSSL verifies example.com, but visitors receive a Cloudflare 526 response. The public TLS handshake can succeed while Cloudflare rejects the origin certificate under Full (strict). Renewing the edge certificate would leave that origin problem untouched.

Record which certificate belongs to each connection. The origin might present a separate public certificate or a Cloudflare Origin CA certificate. Match the failure to the corresponding deployment and trust requirements before replacing files or changing an encryption mode.

Visitor -- TLS A --> CDN edge -- TLS B --> origin

TLS A: certificate for example.com verifies
TLS B: origin certificate fails verification

A successful public scan of TLS A does not verify TLS B.

1. Save the public hostname, scan time, connected IP and certificate verification result.
2. Check CDN error details and the configured origin hostname, encryption mode and certificate.
3. Repair the failing connection, then verify origin access and the public page separately.

Reference: Cloudflare: edge and origin certificate concepts

Establish what the public scan actually reached

Confirm that the hostname is proxied. Cloudflare proxied DNS answers normally contain edge addresses; a DNS-only record can take clients directly to the origin. Record apex and www separately because their proxy status, certificate coverage and routing can differ.

CheckSSL selects one resolved address for the connection and reports that address. Its TLS version probes target the same IP. Current scans also discover CAA and attempt leaf-certificate revocation verification through CRLs; these checks do not inspect the private CDN-to-origin connection. Unavailable checks remain unknown, and OCSP and browser CT compliance are not verified.

Keep the SANs, validity dates, issuer and fingerprint with the connection result. A diagnostic certificate obtained after verification fails is evidence for troubleshooting, not a trusted connection. One successful snapshot cannot establish coverage across all IPv4, IPv6 or regional endpoints.

Reference: Cloudflare: proxied and DNS-only records

Test the origin while preserving its expected TLS name

Obtain the origin address and expected TLS hostname from your configuration. Do not assume a public DNS answer identifies the origin. If the CDN overrides origin SNI or the HTTP Host header, reproduce those configured values deliberately. The example assumes both names are example.com.

This command targets a documentation-only IP; substitute an origin you administer. --resolve preserves the URL hostname for SNI and verification, while --noproxy connects directly. For a publicly trusted origin certificate, omit --cacert and use your current CA store. For Origin CA, use the appropriate CA certificate obtained independently from Cloudflare’s official documentation.

The CA file must be a known trust anchor, not the leaf or arbitrary chain downloaded from the failing server. Do not replace verification with -k. Direct access may require an approved network path or configured client authentication; a firewall rejection does not prove a certificate fault.

curl -q -v --max-time 15 --noproxy '*' \
  --resolve 'example.com:443:192.0.2.10' \
  --cacert /path/to/verified-origin-ca.pem \
  'https://example.com/' -o /dev/null

Reference: curl: verify certificates with a known CA store

Apply the correct origin trust requirements

Before enabling Cloudflare Full (strict), make sure the origin accepts HTTPS on port 443 and serves a currently valid certificate matching the requested or target hostname. Cloudflare accepts certificates issued by a publicly trusted CA or its Origin CA. Deploy the required chain and test the configured hostname before changing the mode.

Origin CA certificates are intended for Cloudflare-to-origin traffic and are not trusted directly by ordinary browsers. A browser warning during direct access can therefore reflect the wrong trust environment rather than failed Cloudflare validation. Disabling proxying to investigate can expose that warning to visitors; use a controlled origin test instead.

Repair an expired certificate, missing chain or wrong hostname assignment at the origin. Reducing verification or turning off HTTPS hides the requirement rather than completing the repair. Keep renewal and deployment configured for both connections.

Reference: Cloudflare: Full (strict) requirements

Confirm the fix across the routes visitors use

A changed fingerprint alone does not mean failure. CDNs renew certificates and may select different valid certificates for different handshakes. Compare hostname coverage, validity and successful verification first. Record client, IP and time when investigating inconsistent results; do not require every valid endpoint to share one fingerprint.

1. Repair the identified edge or origin assignment and use the provider-supported deployment or reload process.
2. Repeat the targeted origin check with its intended hostname and CA trust, then request the public page through the CDN.
3. Retest supported host aliases and IPv4/IPv6 paths; use additional regional checks when the failure was location-dependent.
4. Confirm the origin error is gone and retain separate renewal monitoring for edge and origin certificates.

Reference: Cloudflare: certificate selection and presentation