← Knowledge base

Check Cloudflare, one connection at a time

A Cloudflare-fronted website has separate TLS connections. First check the visitor-to-edge connection. Then inspect Cloudflare-to-origin negotiation. A green public scan cannot establish what happens behind the edge or inside your application.

Before you start

You need the proxied hostname and the OpenSSL walkthrough prerequisites, or use the free domain scan. To investigate the origin, also arrange access to the zone's settings and your origin's private TLS telemetry. A visitor without that access should record origin readiness as unknown and ask the website operator.

Cloudflare documents hybrid TLS support at the edge and separate origin capabilities. This is product documentation, not evidence for an individual connection. See Cloudflare's connection model.

Validation scope: this is a documentation-reviewed procedure. Examples are illustrative and do not assert that your zone, tunnel, or origin was tested.

1. Verify visitor-to-edge TLS

Confirm in your DNS/zone configuration that the hostname is actually proxied. A DNS-only record goes directly to its destination. Then run this read-only network check:

# POSIX shell; substitute your proxied hostname.
target='example.com'
openssl s_client -connect "$target:443" -servername "$target" \
  -verify_hostname "$target" -verify_return_error \
  -tls1_3 -groups X25519MLKEM768 -brief -no_ign_eof </dev/null

Require successful certificate verification, TLS 1.3, and the selected X25519MLKEM768 group. If it fails, use the classical comparison and troubleshooting table. Missing local group support does not diagnose Cloudflare.

Illustrative evidence record:

Hop: visitor → Cloudflare edge
Client: recorded OpenSSL executable and version
Protocol: TLSv1.3
Selected group: X25519MLKEM768
Certificate verification: OK
Origin hop: not assessed by this connection

Repeat from the application or network you care about. A corporate TLS inspection proxy can change the connection path; preserve its presence in your record.

2. Verify Cloudflare-to-origin TLS

1. Identify the actual origin listener or tunnel, TLS library, and supported groups. For nginx, follow the origin and telemetry walkthrough.
2. Review the zone's Automatic key exchange settings, including configured requirements. Check all origins when a zone uses multiple servers.
3. Send a controlled request that reaches the origin. Use a test route configured to bypass cache; a cached response cannot show a new origin handshake.
4. Inspect the selected group in your origin's private telemetry for the Cloudflare connection. Allow for existing pooled connections and retest after they renew.

Current Cloudflare documentation says Automatic key exchange is enabled for existing zones and by default for new zones. The older Origin Post-Quantum Encryption API remains available but is a no-op; calling it does not change behavior. Use the current origin guidance instead of old API recipes.

A direct OpenSSL connection to the origin can show what that server accepts. It does not prove what Cloudflare selected. Keep origin access restrictions and certificate validation in place throughout testing.

3. Interpret mixed results

4. Remediate, retest, and preserve recovery

Capture current zone and origin settings before a change. Upgrade an origin through its supported deployment process, test one origin or staging hostname, and verify both hops plus ordinary application requests. Keep an approved recovery configuration available. Restore the specific changed setting/image if connectivity regresses, then repeat the checks and record the remaining migration work.

Use an origin encryption mode that verifies the origin certificate; Full (strict) documents its trust requirements. Weakening certificate checks or exposing a protected origin is not a fix for missing PQC support.

For Cloudflare Tunnel, follow the connector's supported setup and record that path separately. Tunnel evidence cannot be inferred from an unrelated public listener.

Next: authentication and internal services

Key exchange and signatures are separate. Cloudflare's current origin documentation describes ML-DSA support for Authenticated Origin Pulls and Custom Origin Trust Store, with specific library, certificate, and encoding requirements. That does not establish post-quantum browser-facing certificates. Treat any certificate migration as its own interoperability project: start with certificates and software signatures, then capture every hop in the worksheet.

Documentation reviewed 25 September 2026, including Cloudflare origin guidance updated 3 August 2026. Dashboard controls and product support can change; check the linked sources before changing a zone.