Where TLS is terminated, and who holds the key

Every application-layer check — a WAF rule, request-logic analysis, file scanning — requires unencrypted content.

So TLS is terminated wherever the protection sits. That is a technical inevitability, and a vendor who obscures it is steering the conversation away from the real question.

The real question starts after it: what is retained at the termination point, who holds the key, and how is the decrypted traffic carried onward?

The first option terminates at the provider’s edge. This is the simplest and by far the most common: the certificate lives with the provider, traffic is decrypted, inspected and passed to the origin.

The second terminates on a device or application inside your own network. The provider only forwards packets. Control is preserved, but protection only exists where you installed it.

The third is mixed: termination at the edge with the key under your control. It is the most complex arrangement, and for many regulated industries it is the only acceptable one.

The most commonly forgotten stretch is the one between the edge and the origin. The user reaches the edge over TLS, but if the edge talks to the origin over plain HTTP, the traffic travels in the clear.

This usually rests on the assumption that the internal network is safe. In practice that path frequently crosses the internet and is exposed.

The correct configuration is a second TLS connection and, where possible, mutual authentication. Then the origin accepts traffic only from the edge, and nobody else can connect to it directly.

The simplest case stores the certificate and private key with the provider. It works, and you have handed a key to another organisation.

The second option keeps the key in a hardware module and lets the provider request a signing operation. The key itself never leaves.

The third is bringing your own key. By name it grants control; in practice the key still ends up inside the provider’s environment. Choosing without understanding the difference is not really choosing.

An expired certificate is the most common and most preventable cause of downtime. It always happens on a public holiday or on a Friday night.

The answer is automated renewal, and that needs supervision too: an alert about a failed renewal has to arrive weeks before expiry, not on the day.

And renewal has to happen everywhere. A certificate renewed at the edge but left stale at the origin breaks mutual authentication — and that failure is invisible from outside.

TLS 1.0 and 1.1 are no longer needed anywhere and should be disabled. That is usually an easy decision, because almost no clients still use them.

The harder question is the cipher list in TLS 1.2. Weak options survive there, and they are usually retained "for older clients".

The practical technique is to look at the statistics: how many connections arrived over each protocol and cipher last month. It usually turns out the older clients are scanners and bots.

The assumption that only you can obtain a certificate for your domain is wrong. Anyone who takes control of a DNS record, or claims an abandoned subdomain, can obtain one too.

So certificate transparency logs are monitored: every new certificate for your domain is visible. An unexpected certificate is an event to investigate immediately.

The second control is a CAA record, listing which certificate authorities may issue for your domain. It is one line, and it closes a number of routes at once.

Four questions for a provider. Where is traffic decrypted? Where is the private key stored, and who can see it? Is the leg from edge to origin encrypted, and is mutual authentication in place there?

The fourth is about logging: what part of the decrypted traffic is retained? If request bodies are stored in full, you have moved customer data somewhere else, and you need to know it.

And one question for yourself: can anyone reach the origin directly, bypassing the edge? If they can, everything above is irrelevant — an attacker simply goes around it.