TLS provides confidentiality and identity for a connection. The handshake agrees on a cipher, proves the server’s identity with a certificate, and derives a shared key, all before any application data flows. TLS 1.3 shortens this to a single round trip and drops the weaker options.
Before you start
You should understand TCP and public-key cryptography at a high level. This article covers the handshake and certificate validation.
Step-by-step walkthrough
Step 1: Agree on parameters and keys
The client offers supported versions and cipher suites, and the server selects one. With TLS 1.3 the client also sends a key share, so the shared secret is derived in one round trip. The agreed cipher protects the rest of the session with symmetric encryption.
Step 2: Validate the certificate
The server presents a certificate chain. The client checks that the chain leads to a trusted root, that the certificate covers the requested hostname, and that it is within its validity dates. A failure in any of these aborts the connection, which is why an expired or misnamed certificate breaks HTTPS.
Step 3: Know what changed in TLS 1.3
TLS 1.3 removes obsolete ciphers and features such as renegotiation, uses an ephemeral key exchange by default for forward secrecy, and supports ALPN to negotiate the application protocol — including HTTP/2 and HTTP/3. It is faster and safer, so new services should require it.
Worked scenario
The handshake details are visible with openssl.
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
| grep -E 'Protocol|Cipher|subject='
# Protocol: TLSv1.3
# Cipher : TLS_AES_256_GCM_SHA384Walk through the example
The output shows the negotiated Protocol and Cipher, confirming the version and suite actually used. -servername sends the hostname so the server returns the right certificate, which matters on shared hosting. If the certificate were expired or named differently, the handshake would fail here.
Common mistake
Letting a certificate expire, which fails every connection, or using a certificate that does not list the hostname in its subject or SAN, which fails validation. Disabling verification to silence the error removes the identity guarantee entirely.
Verify the behavior
Run openssl s_client and confirm the protocol is a modern version and the certificate matches the hostname. Check the certificate dates and chain. Connect with an expired certificate and observe the validation failure.
Interview exercise
Why does TLS 1.3 complete in fewer round trips than TLS 1.2?
Answer and reasoning
In TLS 1.3 the client sends its key share with the first flight, so the server can derive the shared secret and respond in the same round trip rather than negotiating parameters first and exchanging keys in a later one. Combined with removing legacy options, this cuts the handshake to one round trip and enables zero-round-trip resumption in suitable cases.
Continue learning
Compare identity concerns in TLS identity and protocol versions in HTTP/3 and QUIC. Read the MDN TLS documentation and try the Networking interview questions.