Moving a Cloudflare site to Full strict TLS safely

Full (strict) encrypts the Cloudflare-to-origin connection and validates the origin certificate. Use it after every relevant origin presents an unexpired certificate covering the expected hostname.

Prepare for the change

Check the hosting certificate and chain, HTTPS listener and firewall access. A publicly trusted certificate or suitable Cloudflare Origin CA certificate can work, but their direct-browser trust differs.

01 Move a Cloudflare site to Full strict TLS safely

  1. Test HTTPS on the intended origin with the correct hostname and SNI. Confirm certificate dates, names and chain.
  2. Open the domain’s SSL/TLS > Overview page in Cloudflare.
  3. Choose the encryption-mode control and select Full (strict), reviewing any automatic-mode or hostname-specific settings that also apply.
  4. Test the homepage and important dynamic paths through the proxied hostname. Inspect origin and Cloudflare errors if a request fails.
  5. Record the certificate renewal process and monitor it so a later expiry does not interrupt validated origin connections.

02 Example: inspect HTTPS at a specific origin without changing public DNS

For an origin using a publicly trusted certificate, replace the example hostname and documentation IP with your verified origin details. Run this only from a network allowed to reach that origin. The URL keeps the real hostname for the HTTPS request while --resolve selects the test destination.

Command example
curl --silent --show-error --dump-header - --output /dev/null \
  --connect-timeout 3 --max-time 15 \
  --resolve 'www.example.com:443:192.0.2.10' \
  'https://www.example.com/'

Keep certificate verification enabled. An origin that uses Cloudflare Origin CA has a different trust setup, so a normal public trust store is not the complete test for that certificate. An origin restricted to Cloudflare addresses may deliberately reject your direct connection.

Expected result: the approved test reaches the intended origin with valid hostname coverage and a meaningful HTTP response. Then verify the proxied website separately; direct success does not establish Cloudflare reachability.

Confirm the expected result

Visitors should receive valid HTTPS through Cloudflare, and the origin connection should also be encrypted and authenticated. Confirm alternate origin hostnames if routing rules use them.

If the change does not work

Error 526 indicates certificate validation trouble; error 525 points to a TLS handshake failure. Fix the origin issue rather than treating Flexible mode as a permanent repair. Flexible leaves the origin leg on HTTP and can cause redirect loops.

Is Full without strict validation equivalent?

No. Full encrypts the origin connection but does not apply the same certificate validation. A working encrypted connection and a verified origin identity are different properties.

Sources and further reading

  • 0 Users Found This Useful
  • performance, security-ssl
Was this answer helpful?

Related Articles

Diagnosing a pending Cloudflare edge certificate

An edge certificate protects the browser-to-Cloudflare connection. If its status remains...

Enabling HSTS only after all required hostnames support HTTPS

HSTS tells browsers to require HTTPS for a period of time. Enable it only after HTTPS is...

Finding mixed content when HTTPS works through Cloudflare

Mixed content occurs when an HTTPS page requests assets through HTTP. The main certificate can...

Installing a Cloudflare Origin CA certificate and understanding its trust

Cloudflare Origin CA certificates secure traffic between Cloudflare and a proxied origin. They...

Diagnosing Cloudflare error 525 during the origin TLS handshake

Cloudflare error 525 means its TLS handshake with the origin failed. The browser may already...