Client-to-edge TLS and edge-to-origin TLS are separate connections, with separate certificates, names, and trust settings.

Managed or custom

Managed Let's Encrypt covers ordinary hostnames. Custom SSL is for names and issuance you already operate. SNI and TLS version policy sit on the distribution.

The delivery model

How it works

TLS 1.3 CDN

  1. 01Client TLSValidate the public hostname at the edge.
  2. 02Edge policyApply supported protocol and HTTPS behavior.
  3. 03Origin TLSValidate the upstream certificate and expected name.
Conceptual model for this configuration. The actual path depends on provider policy and application behavior.

Force HTTPS at the edge

HTTP redirects should not depend on the application. Cloud CDN can force HTTPS so origin never spends a worker on a 301.

0-RTT and HTTP/3

TLS 1.3 with 0-RTT shortens repeat connections. Pair it with HTTP/3 at the same PoPs.

Origin TLS is separate

Validate the origin certificate on pull even when the public certificate is managed. Two TLS hops, two jobs.

Validate before production

Test the full redirect chain, public certificate renewal, and upstream hostname verification. Review 0-RTT replay risks before enabling early data for application requests. Confirm behavior for clients that require a supported fallback.

  • Record the configuration and expected result before changing traffic.
  • Keep evidence of the test and a working rollback for the previous behavior.

Sources & further reading