Transport Layer Security (TLS), Public Key Infrastructure (PKI), and mTLS

Transport Layer Security (TLS) provides end-to-end cryptographic privacy, authentication, and data integrity over TCP networks. This guide covers the TLS 1.3 handshake protocol, Public Key Infrastructure (PKI) certificate trust chains, OCSP stapling, automated certificate lifecycle management (ACME / Let's Encrypt), and Mutual TLS (mTLS) in zero-trust architectures.

⚡ Quick Dive

TLS 1.2 vs. TLS 1.3 Comparison

Feature TLS 1.2 (Legacy Standard) TLS 1.3 (Modern Standard)
Handshake Latency 2 RTT (Round Trip Times) ⚡ 1 RTT (0-RTT with Early Data)
Static RSA Key Exchange Allowed (No Forward Secrecy) ❌ Completely Removed
Allowed Ciphers Hundreds (Weak ciphers CBC, RC4 allowed) Only 5 modern AEAD ciphers (AES-GCM, ChaCha20)
Encrypted Handshake Certificate sent in plain text 🔒 Certificate payload is fully encrypted

Essential openssl Inspection Commands

# 1. Connect to server, test TLS 1.3 handshake, and print certificate chain
openssl s_client -connect example.com:443 -tls1_3 -servername example.com

# 2. Inspect expiration date and Subject Alternative Names (SAN) of local cert
openssl x509 -in cert.pem -text -noout | grep -E "Not After|DNS:"

# 3. Verify that a private key matches a certificate (modulus check)
openssl rsa -in privkey.pem -modulus -noout | openssl sha256
openssl x509 -in cert.pem -modulus -noout | openssl sha256

📖 Extended Guide

1. TLS 1.3 1-RTT Handshake Architecture

TLS 1.3 combines key exchange negotiation and cryptographic parameters into a single round-trip:

Client                                                         Server
  │                                                              │
  │ ─── ClientHello (Supported Ciphers + ECDH KeyShare) ───────► │
  │                                                              │ (Server calculates Shared Secret)
  │ ◄── ServerHello (Selected Cipher + Server KeyShare) ──────── │ (Encrypted from here down)
  │ ◄── EncryptedExtensions + Certificate + CertificateVerify ── │
  │ ◄── Finished (HMAC Signature) ────────────────────────────── │
  │                                                              │
  │ ─── Finished (HMAC Signature) ─────────────────────────────► │
  │ ─── [ Encrypted Application Data (HTTP) ] ─────────────────► │

2. X.509 Certificate Chain of Trust

Operating systems and browsers ship with pre-installed Root CA (Certificate Authority) public certificates in their trust stores:

[ Root CA (e.g. ISRG Root X1) ] (Self-Signed, Stored in OS Trust Store)
               │ (Signs Intermediate)
               ▼
[ Intermediate CA (e.g. Let's Encrypt R3) ] (Keeps Root offline/airgapped)
               │ (Signs Leaf Certificate)
               ▼
[ Leaf / End-Entity Certificate (*.example.com) ] (Installed on Nginx Server)
  • When configuring web servers, always provide the Full Chain (fullchain.pem), which contains both the Leaf and Intermediate certificates, so clients can verify the path back to their trusted root.

3. Certificate Revocation & OCSP Stapling

If a private key is compromised, the certificate must be revoked before its expiration date.

  • OCSP (Online Certificate Status Protocol): The client contacts the CA's server directly to verify validity. This adds latency and creates a privacy leak (CA sees what domains users visit).
  • OCSP Stapling: The web server queries the CA periodically, caches the signed OCSP response, and "staples" it directly to the TLS handshake. This eliminates client lookup latency and protects user privacy.
# Enable OCSP Stapling in Nginx
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/letsencrypt/live/example.com/chain.pem;
resolver 1.1.1.1 8.8.8.8 valid=300s;

4. Mutual TLS (mTLS) for Zero-Trust Microservices

In standard TLS, only the server proves its identity to the client. In Mutual TLS (mTLS), both the client and server present X.509 certificates to each other:

Client (e.g., Order Service)                             Server (e.g., Payment Gateway)
  │ ◄── Server Certificate ─────────────────────────────── │ (Client verifies Server)
  │ ─── Client Certificate ──────────────────────────────► │ (Server verifies Client)

mTLS forms the cryptographic foundation of Kubernetes Service Meshes (Istio, Linkerd), guaranteeing authenticated, encrypted zero-trust communication across internal pod-to-pod traffic.

⌂ All Guides