Terminating TLS at the CDN edge moves the handshake from a round trip you can't shorten to one you can. A cold TLS 1.3 connection costs two round trips over TCP — one for the SYN exchange, one for ClientHello/ServerHello — so at a 15 ms edge RTT you pay about 30 ms before the request is even readable, versus roughly 240 ms if that same handshake lands on an origin 120 ms away. That gap, multiplied across every cold connection from mobile clients, is the entire argument for TLS termination at the edge. What it costs you instead: certificate distribution, ticket-key coordination, and a cipher policy you now own in two places.
In the common configuration, the client's TLS session ends at the edge node that accepted the TCP or QUIC connection. The edge holds the leaf certificate and private key for the hostname in SNI, decrypts, applies caching and routing logic, then opens a separate TLS session to the origin over a pooled, long-lived connection. Two independent sessions, two independent cipher policies, one shared trust decision.
The alternative shapes are worth naming precisely. TLS passthrough (layer-4 proxying) preserves end-to-end encryption to the origin but forfeits caching, compression, request coalescing, and HTTP/3 — you are buying a TCP relay. Keyless designs keep the private key on customer infrastructure and ask a remote key server to perform the signature during each full handshake, which adds one network round trip to the handshake critical path; delegated credentials (RFC 9345, maximum 7-day validity) exist specifically to remove that per-handshake call.
| Setup path | RTTs before request is readable | At 15 ms edge RTT | At 120 ms origin RTT |
|---|---|---|---|
| TLS 1.2 full handshake over TCP | 3 | ~45 ms | ~360 ms |
| TLS 1.3 full handshake over TCP | 2 | ~30 ms | ~240 ms |
| TLS 1.3 resumed via PSK ticket, no early data | 2 | ~30 ms | ~240 ms |
| TLS 1.3 with 0-RTT early data over TCP | 1 (TCP only) | ~15 ms | ~120 ms |
| HTTP/3 over QUIC, first connection (RFC 9000) | 1 | ~15 ms | ~120 ms |
| HTTP/3 with 0-RTT resumption | 0 | ~0 ms | ~0 ms |
The single most useful line in that table is the third one: TLS 1.3 session resumption does not save a round trip unless you also enable early data, which is why teams that "turned on resumption" and saw no p75 improvement were measuring correctly.
Terminating TLS at a CDN edge 15 ms from the client instead of an origin 120 ms away cuts a cold TLS 1.3 handshake from roughly 240 ms to roughly 30 ms, because each of the two required round trips is billed at the distance to whatever holds the private key. As of 2026, HTTP/3 over QUIC (RFC 9000) collapses transport and TLS setup into a single round trip, bringing the same edge connection to about 15 ms.
Latency math is the easy half. The operational cost of edge TLS is distributing keys and certificates to every node that might answer a given SNI, then keeping them consistent.
Three failure patterns recur. First, SNI cache misses: edges that lazily fetch certificates on first request add 50–200 ms to the first handshake for a hostname, which looks like random p99 spikes on low-traffic domains. Second, ticket-key divergence — stateless TLS 1.3 tickets are only decryptable by nodes holding the same key, so an unsynchronised key set silently converts resumptions into full handshakes; resumption rates at scale typically sit in the 40–70% range, and a drop below that is a coordination bug, not client behaviour. Third, renewal races: ACME issuance succeeds, propagation to edges lags, and a fraction of nodes serve an expiring chain for hours.
Rotate ticket keys on a 4–24 hour schedule, keep two or three previous generations for decryption only, and cap ticket lifetime well under the 7-day protocol maximum if forward secrecy matters more to you than resumption rate. Those two goals are directly opposed; pick deliberately.
Certificate algorithm choice is a CPU and bytes decision. An ECDSA P-256 signature costs roughly 25–45 microseconds on a modern x86 core with OpenSSL 3.x, against roughly 0.5–1.5 ms for RSA-2048 — a 20–40x difference in signing throughput per core, and the reason full-handshake capacity, not bandwidth, is what saturates a TLS terminator during a connection storm. An ECDSA chain also lands near 1.6 KB versus roughly 3.2 KB for an RSA-2048 chain, which matters because the server's first flight has to fit inside the initial congestion window.
Post-quantum key agreement changed that budget. Hybrid X25519MLKEM768 adds roughly 1.1–1.2 KB to the ClientHello and a similar amount to the server's key share, pushing many ClientHellos past a single packet. Vendor-published telemetry through 2025 reported hybrid post-quantum key agreement on roughly a third to half of human-initiated TLS 1.3 connections, rising steadily. Serve a dual certificate set (ECDSA preferred, RSA fallback), leave client cipher preference honoured so AES-less clients get ChaCha20-Poly1305, and stop ordering suites server-side out of habit.
server {
listen 443 ssl;
listen 443 quic reuseport;
http2 on;
http3 on;
ssl_certificate /certs/edge-ecdsa-fullchain.pem;
ssl_certificate_key /certs/edge-ecdsa.key;
ssl_certificate /certs/edge-rsa-fullchain.pem;
ssl_certificate_key /certs/edge-rsa.key;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;
ssl_ecdh_curve X25519MLKEM768:X25519:prime256v1;
ssl_conf_command Ciphersuites TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384;
ssl_session_tickets on;
ssl_session_ticket_key /certs/ticket.current.key;
ssl_session_ticket_key /certs/ticket.prev.key;
ssl_session_timeout 12h;
ssl_early_data on;
ssl_stapling on;
ssl_stapling_verify on;
}
upstream origin_pool {
server origin.internal:443;
keepalive 256;
keepalive_requests 10000;
}
The origin leg is where handshake cost disappears if you let it: 256 warm connections carrying 10,000 requests each amortise the edge-to-origin handshake to statistical noise. Enable origin-side session reuse and mutual TLS if the origin must authenticate the edge, and remember that early data on the client side must never be forwarded as a non-idempotent request — 0-RTT is replayable by design, so restrict it to safe methods.
Most CDNs fold edge TLS into per-GB delivery pricing, which hides two real costs. Legacy dedicated-IP custom certificate hosting is still a line item on some platforms — Amazon CloudFront has listed dedicated IP custom SSL at $600 per month for years, while SNI-based certificates are free. And if you terminate yourself on a cloud load balancer, new-connection rate is often the binding billing dimension: an AWS Application Load Balancer LCU counts 25 new connections per second against 1 GB per hour, so a workload of many short-lived TLS connections bills on handshakes, not bytes. Vendor differences show up in how much of cipher policy and certificate propagation you actually control, which is worth checking against edge TLS configuration options on enterprise CDN infrastructure before you commit. BlazingCDN, for example, exposes per-property configuration and one-hour onboarding, which matters when you are moving a live TLS front door rather than building a new one.
Four checks, in order. Pull the TLS negotiation summary from your edge access logs and confirm the ratio of resumed to full handshakes per node — if it varies by more than a few points between nodes in the same region, your ticket keys are not synchronised. Read secureConnectionStart minus connectStart from W3C Resource Timing in real-user data and look at p95, not p50; cold-connection cost hides above the median. Check whether your negotiated group is a hybrid post-quantum one on modern browsers. Finally, log signature algorithm per handshake and confirm ECDSA is actually winning against your dual certificate set.
Edge termination is the right default for anything cacheable, anything mobile-heavy, and anything where connection setup dominates transfer time — API traffic with small payloads benefits far more than large-file delivery, where a 200 ms handshake is amortised over a 40 MB object. It is the wrong choice when regulatory or contractual terms forbid a third party from holding decryption keys for the payload; in that case, evaluate delegated credentials or layer-4 passthrough and accept that you have given up caching and protocol upgrades in exchange.
No, in any correctly configured deployment. The edge terminates the client session and opens a second TLS session to the origin, so the payload is encrypted on both legs. The origin leg should use TLS 1.2 or 1.3 with certificate verification, and mutual TLS where the origin needs to authenticate the edge rather than trust any client that finds its address.
A full TLS 1.3 handshake costs one round trip on top of transport setup, so two round trips total over TCP and one over QUIC. In practice that is roughly 30 ms against a 15 ms edge and roughly 240 ms against a 120 ms origin. Resumption alone does not reduce the round-trip count; only 0-RTT early data does.
Enable it only for idempotent requests. Early data is replayable by design, so a replayed POST or a state-changing GET can be executed twice. The standard pattern is to allow early data for safe methods, reject or buffer everything else until the handshake completes, and keep an anti-replay window across nodes that share ticket keys.
Hybrid X25519MLKEM768 adds roughly 1.1–1.2 KB to the ClientHello, pushing it beyond one packet. Middleboxes and older TLS stacks that assume a single-packet ClientHello or reject unknown groups will fail instead of negotiating down. Test with a client that supports both hybrid and classical groups, and confirm your terminator falls back to X25519 cleanly.
Take a single high-traffic hostname and split its real-user Resource Timing data into TLS-setup time and everything else, at p50, p95 and p99. Then split again by resumed versus full handshake. Most teams discover that full handshakes are 3–8% of connections but a double-digit share of p99 time to first byte, which reframes the whole conversation: the fix is rarely a bigger cache and often a shorter distance to the key. If your numbers say otherwise, that is a result worth publishing too.