TLS/HTTPS Termination at the Web Server Layer

Web Servers Fundamentals

Chapter 7 · TLS/HTTPS Termination at the Web Server Layer

Chapter 6 named TLS termination as one of the standalone reasons to put a reverse proxy in front of a single backend. This chapter is that idea, addressed directly — not a re-explanation of what a certificate or a TLS handshake actually is (HTTPS/TLS Fundamentals already covers that thoroughly), but specifically where and how each of the three web servers plugs into that handshake.

What "Termination" Actually Means

TLS termination is the point in the request path where encrypted traffic gets decrypted back into plain HTTP — the server or reverse proxy handling that decryption is said to "terminate" the TLS connection there. This is distinct from TLS passthrough, where a proxy forwards the still-encrypted traffic onward without decrypting it itself, leaving termination to happen further down the chain, at the actual backend. Most of the setups this course discusses terminate TLS at the web server or reverse-proxy layer, with the connection to any backend behind it handled separately.

Apache's TLS Configuration

<VirtualHost *:443>
    ServerName example.com
    SSLEngine on
    SSLCertificateFile /etc/ssl/certs/example.com.crt
    SSLCertificateKeyFile /etc/ssl/private/example.com.key
</VirtualHost>

Apache's mod_ssl module adds the SSLCertificateFile/SSLCertificateKeyFile directives (and SSLCertificateChainFile where an intermediate chain is needed) inside a <VirtualHost> listening on port 443. Per Chapter 4's own per-VirtualHost model, a server hosting several domains typically needs its own certificate configuration per VirtualHost, unless SNI (Server Name Indication) is relied on to let one shared connection still resolve to the right certificate per domain — supported by all three servers covered in this course.

Nginx's TLS Configuration

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate /etc/ssl/certs/example.com.crt;
    ssl_certificate_key /etc/ssl/private/example.com.key;
}

Nginx's equivalent lives inside a server {} block: listen 443 ssl to accept HTTPS connections, plus ssl_certificate/ssl_certificate_key pointing at the certificate and private key files — the same underlying concept as Apache's directives, again per-server-block, matching Chapter 4's own per-site model.

IIS's TLS Configuration

IIS handles certificates differently at a structural level: rather than pointing at certificate files on disk, IIS integrates with the Windows Certificate Store — certificates are imported into that store, then an https binding (Chapter 4's own binding concept) is configured in IIS Manager to pair a specific certificate from the store with a specific site. This is a genuine architectural difference from Apache's and Nginx's file-based approach, not just a different way of pointing at the same kind of file.

	Apache	Nginx	IIS
Certificate source	Files on disk	Files on disk	Windows Certificate Store
Config mechanism	`SSLCertificateFile`/`SSLCertificateKeyFile`	`ssl_certificate`/`ssl_certificate_key`	HTTPS binding referencing a stored certificate
Scope	Per VirtualHost	Per server block	Per Site binding
SNI support	Yes	Yes	Yes

This chapter assumes HTTPS/TLS Fundamentals

What a certificate authority actually verifies, what the TLS handshake itself involves, and why a certificate chain matters are all covered in HTTPS/TLS Fundamentals — this chapter deliberately doesn't repeat that material, and instead only covers where each of these three specific web servers plugs a certificate into that already-understood process.

Termination doesn't automatically mean the whole path stays encrypted

It's easy to assume that once HTTPS is set up at the web server, "the connection is encrypted" end to end. In practice, once TLS is terminated at the web server or reverse-proxy layer, the connection onward to an actual backend application — per Chapter 6's own reverse-proxy material — is very often plain, unencrypted HTTP internally, unless deliberately re-encrypted for that hop. This is a common and reasonable choice inside a trusted private network, but it's a real design decision worth being aware of, not an automatic guarantee that comes bundled with "HTTPS is enabled."

Hands-On Exercises

Exercise 1

Write the Nginx server block that terminates HTTPS for shop.example, using certificate files at /etc/ssl/certs/shop.crt and /etc/ssl/private/shop.key.

📄 View solution

Exercise 2

A colleague assumes that because their site shows a padlock and "https://" in the browser, every hop of that request's journey — including from the reverse proxy to the backend application — must be encrypted. Using this chapter's own warning box, explain what's actually true here.

📄 View solution

Exercise 3

Explain why IIS's Windows Certificate Store approach is a genuine architectural difference from Apache's and Nginx's file-based certificate configuration, rather than just a different syntax for pointing at the same underlying thing.

📄 View solution

Chapter 7 Quick Reference

TLS termination — the point where encrypted traffic is decrypted back to plain HTTP, distinct from passthrough
Apache: SSLCertificateFile/SSLCertificateKeyFile per VirtualHost. Nginx: ssl_certificate/ssl_certificate_key per server block. IIS: an HTTPS binding referencing the Windows Certificate Store
All three support SNI, letting one shared connection resolve to the right certificate per domain
Terminating TLS at the web server does not automatically mean the hop to a backend application stays encrypted — that's a separate, deliberate decision