SSL termination, also called TLS termination, is the process of decrypting HTTPS traffic at a specific point in the network infrastructure before passing it onward to backend servers. The encrypted connection that a browser establishes with a server is terminated, ended, at a designated component, a load balancer, reverse proxy, CDN edge node, or dedicated SSL termination device, rather than being maintained all the way to the application server that ultimately handles the request.

The term termination describes exactly what happens, the TLS encrypted connection is terminated at one point and the traffic continues beyond that point in a different form. After termination the request travels from the termination point to the backend server, typically over an internal network, either unencrypted or re-encrypted with a new TLS connection for the internal segment.

SSL termination exists because handling the computationally intensive TLS decryption and encryption on every application server in a fleet is inefficient. Concentrating SSL processing at dedicated termination points, load balancers or reverse proxies, allows application servers to focus on application logic while the termination layer handles cryptographic operations. SSL termination also enables infrastructure components, load balancers, CDNs, WAFs, to inspect and act on request content that would be opaque if the encryption were maintained end to end.

For redirect management SSL termination is the point at which redirect infrastructure examines incoming HTTPS requests, reads the Host header, the request path, and other request attributes, to determine which redirect rule applies and what Location header to return. Without SSL termination the redirect infrastructure cannot read the request content and therefore cannot apply redirect rules.

How SSL termination works

SSL termination involves several steps, from receiving the encrypted client connection through processing the decrypted request and optionally re-encrypting for backend communication.

Client connection to termination point: a browser establishes an HTTPS connection to the SSL termination point. This is a standard TLS handshake: the termination point presents its SSL certificate for the requested domain, the browser verifies the certificate, and an encrypted session is established. The browser has no knowledge that the termination point is a proxy, from the browser’s perspective it is connected directly to the server for the requested domain.

For SSL termination to work the termination point must have a valid SSL certificate for every domain whose traffic it terminates. A load balancer terminating HTTPS for example.com must have a certificate covering example.com. A CDN terminating HTTPS for thousands of customer domains must have certificates for each of them. Managing certificates at scale is one of the primary operational challenges of SSL termination infrastructure.

TLS decryption: the termination point decrypts the incoming HTTPS request using the session keys established during the handshake. The decrypted content, the HTTP request headers, body, and all other request data, becomes accessible in plaintext at the termination point. The termination point can now read the request, the Host header, the URL path, the HTTP method, any cookies, and all other request attributes.

Request processing: with the request decrypted the termination point can inspect and act on it. Load balancers use request attributes for routing decisions, distributing requests across backend servers based on content, load, or session affinity. WAFs, Web Application Firewalls, inspect request content for malicious patterns. Redirect management infrastructure reads the Host header and path to determine which redirect rule applies.

Backend forwarding: after processing the decrypted request the termination point forwards it to a backend server. This forwarding takes one of two forms.

Unencrypted forwarding, the request is forwarded over HTTP on the internal network. The backend server receives a plain HTTP request. This is appropriate when the internal network is trusted and secure, within a private VPC or data center network where traffic is not exposed to untrusted parties. The backend does not need SSL certificates and does not perform TLS processing.

Re-encrypted forwarding, the request is re-encrypted with a new TLS connection from the termination point to the backend server. Also called SSL bridging or end-to-end TLS. The backend server requires SSL certificates and handles TLS decryption for the internal segment. This provides encryption for the entire path from client to backend, appropriate when internal traffic traverses untrusted networks or when compliance requirements mandate end-to-end encryption.

Response path: the backend server sends its HTTP response to the termination point. The termination point receives the response and encrypts it with the session keys from the original client connection. The encrypted response is sent back to the browser. The browser decrypts the response and displays the content.

Where SSL termination happens

SSL termination can be implemented at several different infrastructure layers, each with different trade-offs in terms of capability, performance, and operational complexity.

Load balancers: one of the most common SSL termination locations. Hardware load balancers, F5, Citrix ADC, and software load balancers, HAProxy, Nginx, AWS ELB, Google Cloud Load Balancing, all support SSL termination. The load balancer terminates HTTPS from clients, distributes decrypted requests across backend application servers, and encrypts responses before returning them to clients.

Load balancer SSL termination provides a natural centralisation point for certificate management, all certificates for all domains are managed at the load balancer rather than on every individual application server. Scaling the application server fleet does not require managing certificates on new servers.

Reverse proxies: dedicated reverse proxy servers, Nginx, Apache with mod_proxy, Caddy, Traefik, sit between clients and application servers, terminating SSL and forwarding decrypted requests. Reverse proxies provide additional capabilities alongside SSL termination, caching, compression, header manipulation, URL rewriting, and access control.

CDN edge nodes: CDNs terminate SSL at edge locations distributed worldwide, each edge location close to users geographically. When a browser connects to a CDN-served domain the TLS handshake occurs with the nearest CDN edge node rather than with the origin server. The edge node terminates SSL, applies CDN-level processing, caching, WAF rules, redirect rules, and forwards cache misses to the origin.

CDN edge SSL termination provides the lowest latency TLS handshakes, the TLS round trips happen to a nearby edge node rather than to a potentially distant origin server. Cloudflare, Fastly, Akamai, and other CDNs all terminate SSL at the edge as a fundamental part of their service.

Dedicated SSL termination appliances: specialised hardware or software components designed specifically for SSL termination at high volume. These appliances use hardware cryptographic acceleration, dedicated chips for AES encryption and public key operations, to handle TLS processing at throughput rates that would require many general-purpose servers to match. Used in high-volume environments where SSL processing is a bottleneck.

Application servers: SSL can be terminated directly at the application server, the Nginx or Apache process on the application server itself handles TLS alongside serving application requests. This end-to-end approach means the application server handles both SSL processing and application logic. Appropriate for simpler architectures without dedicated termination infrastructure but less scalable than dedicated termination layers.

SSL termination and redirect management

SSL termination is the layer at which redirect management infrastructure processes HTTPS requests. Understanding this relationship clarifies how redirect services work and why SSL certificates on redirect source domains are essential.

Redirect decisions require decrypted requests: a redirect management server cannot determine which redirect rule to apply to an encrypted request, the request content is opaque while encrypted. Only after SSL termination decrypts the request can the redirect server read the Host header, identifying which domain is being requested, and the URL path, identifying which redirect rule applies. SSL termination is the prerequisite for redirect rule processing.

Certificate management at termination point: redirect management platforms terminate SSL for all connected domains. Each domain connected to the platform requires an SSL certificate, the termination point presents the appropriate certificate for whichever domain is being requested. Managing certificates for potentially hundreds of connected domains requires automation, dedicated redirect management platforms provision certificates automatically through Let’s Encrypt or similar ACME-based CAs for every connected domain.

SNI, Server Name Indication: SSL termination for multiple domains on shared infrastructure relies on SNI, a TLS extension that allows the client to specify which domain it is connecting to during the handshake before the certificate is presented. Without SNI a server hosting multiple domains would not know which certificate to present during the handshake, it could only present one certificate for all connections. SNI allows the client to include the requested domain name in the Client Hello, the termination point reads this and presents the appropriate certificate.

SNI is supported by all modern browsers and is the standard mechanism for shared SSL termination infrastructure. Redirect management platforms that handle many domains on shared infrastructure depend on SNI to present the correct certificate for each connected domain.

HTTP header forwarding: when SSL is terminated at a proxy or load balancer and the request is forwarded to a backend server the backend server receives an HTTP request rather than an HTTPS request. The backend does not know whether the original client connection was HTTP or HTTPS unless the proxy adds headers communicating this information. The X-Forwarded-Proto header is the standard mechanism, the proxy sets X-Forwarded-Proto: https when the original client connection was HTTPS. Redirect rules that differentiate between HTTP and HTTPS source URLs must read this header rather than the connection protocol when running behind SSL termination.

SSL offloading vs SSL bridging vs end-to-end TLS

Three related terms describe different approaches to handling TLS in multi-tier infrastructure, each with different security characteristics and use cases.

SSL offloading: synonymous with SSL termination. The TLS connection from the client terminates at the offloading point. Traffic between the offloading point and backend servers is unencrypted. The term offloading emphasises the computational benefit, TLS processing is offloaded from application servers to dedicated infrastructure. Appropriate for internal networks where traffic between tiers is trusted.

SSL bridging: the TLS connection from the client terminates at an intermediate point, a load balancer or proxy, and a new TLS connection is established from that point to the backend server. The intermediate point decrypts the traffic and re-encrypts it for the internal segment. The backend server requires SSL certificates and handles TLS processing for the internal connection. Provides end-to-end encryption while still allowing the intermediate point to inspect and process request content.

End-to-end TLS: encryption is maintained from the client all the way to the application server without termination at an intermediate point. The intermediate load balancer or proxy passes encrypted traffic through without decrypting it, operating at the TCP level rather than the HTTP level. The application server handles SSL termination. Provides the strongest security for internal traffic but prevents intermediate components from inspecting or modifying request content, the load balancer cannot read HTTP headers for routing decisions and redirect infrastructure cannot read request content for redirect rule matching.

End-to-end TLS without intermediate inspection is incompatible with most redirect management approaches, the redirect infrastructure must be able to read request content to apply rules.

SSL termination security considerations

SSL termination introduces security considerations beyond those of direct end-to-end encrypted connections.

Trust in internal network: when SSL is terminated and traffic forwarded unencrypted on the internal network the security of that internal network becomes critical. Compromised internal network access, through a breach of one server or network component, can expose decrypted traffic. Network segmentation, internal firewalls, and access controls protect the internal segment between the termination point and backend servers.

Certificate private key management: SSL certificate private keys must be stored securely at the termination point, hardware security modules, HSMs, provide the strongest protection, storing private keys in tamper-resistant hardware that prevents extraction. At minimum private keys should be protected with appropriate file system permissions and access controls. Compromised private keys allow attackers to impersonate the server and decrypt captured TLS traffic.

Termination point as security perimeter: the SSL termination point becomes a critical security perimeter, it sees all decrypted traffic and must be secured accordingly. Vulnerabilities in the termination layer, Heartbleed in OpenSSL being the most famous example, can expose all decrypted traffic. Keeping termination layer software updated with security patches is critical.

Inspection and manipulation capability: because the termination point decrypts traffic it has the capability to inspect and modify requests and responses. This capability is what enables redirect rules, WAF filtering, and load balancing. It also means a compromised termination point can silently modify traffic, injecting content, capturing credentials, or altering responses. The security of the termination point directly affects the security of all traffic it handles.