How do you set up SSL/TLS termination and manage certificates in NGINX?

Think of SSL/TLS termination like a secure mailroom in an office building. All letters arrive sealed and encrypted. The mailroom opens them, checks they are legitimate, and hands the plain-text contents to the right department. The departments inside never deal with seals or envelopes. In the same way, NGINX handles the TLS connection at the edge, decrypts the traffic, and sends plain HTTP to your backend apps, saving them from the CPU cost of encryption.

To set up TLS termination, you add the ssl parameter to the listen directive and point NGINX to your certificate and key files. The ssl_certificate directive should point to the full chain file -- your certificate plus any intermediate CA certificates bundled together. The ssl_certificate_key directive points to the private key. You control which TLS versions to allow with ssl_protocols and which ciphers to use with ssl_ciphers. The current best practice is to allow only TLS 1.2 and 1.3, turning off older vulnerable versions like TLS 1.0 and 1.1. The ssl_prefer_server_ciphers directive tells NGINX to use its own cipher order instead of the client's, so stronger ciphers get picked first.

When a client starts a TLS handshake, NGINX uses the certificate and private key to do an asymmetric key exchange, then both sides agree on a symmetric session key for the actual data transfer. This handshake is expensive on the CPU, so NGINX offers several ways to speed it up. SSL session caching (ssl_session_cache) stores session data in shared memory so returning clients can skip the full handshake. SSL session tickets (ssl_session_tickets) let the server pack the session state into a ticket and send it to the client, who presents it on the next visit. OCSP stapling (ssl_stapling) lets NGINX fetch and cache the certificate's revocation status from the CA and attach it to the handshake, so the client doesn't need to make a separate request to check if the cert is still valid.

In production, you typically automate certificate management with Let's Encrypt and certbot. Certbot gets free domain-validated certificates and can configure NGINX automatically or use a standalone HTTP challenge. You set up a cron job or systemd timer to run certbot renew on a schedule, with a post-renewal hook that reloads NGINX to pick up the fresh certificates. For companies with their own internal certificate authority, certificates are usually distributed through tools like Ansible. In Kubernetes, cert-manager handles certificate issuance and renewal automatically, storing certs as Kubernetes Secrets that the Ingress Controller mounts on its own.

One critical mistake is providing an incomplete certificate chain. If you only include your server certificate without the intermediate CA certificates, some clients -- especially mobile browsers and API clients with older trust stores -- will fail the TLS handshake with confusing errors. Another common problem is leaving TLS 1.0 or 1.1 enabled, which fails PCI-DSS compliance scans. And if you don't set up automatic renewal, your certificates will eventually expire and cause sudden outages. Always test your TLS setup with tools like ssl-labs.com or testssl.sh, and set up alerts to monitor certificate expiration dates.