SSL monitoring behind Cloudflare: edge and origin certificates

There can be two TLS connections

When a hostname is proxied through Cloudflare, the visitor connects to Cloudflare's edge. Cloudflare makes a separate connection to your origin. A public certificate check against the hostname normally observes the edge certificate. It does not inspect the certificate file installed in your origin's nginx configuration.

This matters when you receive a reassuring expiry report while an origin connection fails. The public certificate can be valid while the origin certificate has expired, the hostname does not match, the origin cannot be reached or the server has stopped listening. Record which connection each check observes.

Keep validation enabled

Cloudflare's Full (strict) mode validates the origin certificate. Origin CA certificates are intended for the Cloudflare-to-origin connection; they are not a replacement for a publicly trusted certificate when visitors connect directly to the server. Do not disable verification in a public monitor merely to make an invalid connection appear healthy.

The official Cloudflare Origin CA documentation explains this trust boundary. The Full (strict) documentation describes the origin validation requirements.

Monitor the public hostname first

Check the canonical HTTPS URL, follow only the redirects you expect and inspect the response content. Test the hostname customers actually use, including its normal TLS server name. A bare IP address is not equivalent to a hostname: it can select a different virtual host or fail certificate name validation.

Use the HTTPS configuration checker for a point-in-time review of the public connection. Follow up with a recurring HTTP monitor so that a broken edge-to-origin connection becomes visible through the website's response. Remember that a cached page may remain available during some origin failures; a carefully designed readiness endpoint can observe a different part of the system.

Check origin expiry through an authorized operational path

For an origin that should not be publicly reachable, inspect certificate expiry on the server or use an authorized private monitoring route. Restrict that route and do not expose administrative ports just to make a third-party test convenient. UptimeMonitor360's public network checks deliberately reject private network destinations.

Record the certificate path, renewal method, nginx reload command and person responsible. Test a renewed certificate before replacing the active file, run the server's configuration validation, then reload gracefully. A certificate written to disk is not proof that the running service is presenting it.

Distinguish expiry from other certificate failures

A long remaining lifetime does not rule out an incomplete chain, wrong name or trust problem. Preserve the exact error instead of grouping every TLS failure under “expired certificate.” The certificate error guide helps separate these cases. After a renewal or DNS change, verify both the public hostname and your authorized origin check, and confirm that alerts still reach the right recipient.