TLS Handshake & Certificates

TLS 1.2 vs 1.3 handshake, certificate chain, mTLS, certificate rotation, and SNI.

Overview

Overview TLS (Transport Layer Security) provides confidentiality, integrity, and authentication for network communications. TLS 1.3 (RFC 8446, 2018) is the current standard; TLS 1.2 is still widely deployed. TLS 1.0 and 1.1 are deprecated.

TLS 1.2 handshake (2 round trips): ClientHello (TLS version, cipher suites, random), ServerHello (chosen cipher, random), Certificate (server's cert chain), ServerKeyExchange (for ECDHE), ServerHelloDone; ClientKeyExchange, ChangeCipherSpec, Finished; ChangeCipherSpec, Finished. Then application data.

TLS 1.3 handshake (1 round trip): ClientHello includes key share (no more separate ServerKeyExchange). Server responds with all handshake messages in one flight. Application data can flow immediately after the server Finished. TLS 1.3 also supports 0-RTT session resumption (caution: 0-RTT data is replay-vulnerable).

Certificate chain: a server certificate is signed by an intermediate CA, which is signed by a root CA. Browsers trust root CAs in their trust store (managed by the OS or browser vendor). The server must send the full chain (leaf + intermediates) so the client can build the trust path to a trusted root.

SNI (Server Name Indication): a TLS extension in ClientHello that tells the server which hostname the client wants. This allows one IP to host multiple TLS sites with different certificates (virtual hosting for HTTPS). Load balancers use SNI to route TLS traffic before termination.

mTLS (mutual TLS): the client also presents a certificate, and the server validates it. Used for service-to-service authentication in microservices (service mesh) and API authentication. Both sides prove their identity cryptographically.

Key concepts

Certificate chain
Leaf cert (server) signed by intermediate CA, signed by root CA. Server must present the full chain. Client validates by building up to a trusted root in its trust store.
SNI (Server Name Indication)
Extension in TLS ClientHello containing the desired hostname. Allows one IP to serve multiple TLS domains. Required for HTTPS virtual hosting.
ECDHE
Elliptic Curve Diffie-Hellman Ephemeral. Key exchange algorithm providing forward secrecy — even if the private key is compromised later, past sessions cannot be decrypted.
mTLS
Both client and server present and validate certificates. Client certificate authentication at the TLS layer. Used in service meshes (Istio, Linkerd) for zero-trust service auth.
Certificate transparency
Public logs of all certificates issued by CAs. Browsers require CT logs for issued certs. Enables detection of mis-issued or fraudulent certificates.

When to use it

  • Debugging "SSL handshake failed" errors with openssl s_client
  • Explaining why HTTPS requires the full certificate chain, not just the leaf certificate
  • Designing mTLS for internal service authentication in a microservices architecture
  • Justifying TLS 1.3 over TLS 1.2 for performance-sensitive services

Interview questions

  • What is mTLS and when would you use it instead of regular TLS?
  • How do you inspect a TLS connection to debug a certificate issue?

Sign up free to read the full topic

More Networking topics

Start free on Cariara · Coding problems · System design studio