Chapter 15
The TLS 1.3 handshake
In one round trip, client and server agree fresh keys with ECDHE, the server proves it holds the certificate's key by signing the handshake, and both confirm nothing was altered.
Topic
TLS is the protocol behind HTTPS. In TLS 1.3 both sides agree a fresh secret with ephemeral key exchange (ECDHE), the server proves who it is by signing the handshake with its certificate's key, and fast symmetric encryption then protects the data.
This hub starts with the ideas underneath (shared keys and key exchange), then covers the handshake, server configuration and the protocol errors you see when the two sides cannot agree.
Plain words first, then the real mechanism, what it looks like at work and why it matters.
Chapter 15
In one round trip, client and server agree fresh keys with ECDHE, the server proves it holds the certificate's key by signing the handshake, and both confirm nothing was altered.
Chapter 1
Symmetric encryption scrambles data with one secret key, and only someone who holds that same key can turn the scrambled data back into readable text.
Chapter 2
A shared secret key must reach each partner without anyone else seeing it, and every pair needs its own key, so sharing secret keys does not scale.
Chapter 4
Two parties can agree a shared secret over an open network without ever sending it, then derive fast symmetric keys from it to protect the actual data.
Chapter 23
In mutual TLS the client also proves who it is, with a certificate and a signature from its private key, so both ends are authenticated before any data flows.
Step-by-step, with real commands and a way to check it worked.
You will have a web server that offers only TLS 1.2 and 1.3 with forward-secret ciphers, staples OCSP only where it still applies, sends HSTS safely, and passes testing.
nginx serves your certificate and its full chain on port 443, with a key that matches, and you have proved it from the outside with OpenSSL and curl.
Apache httpd serves your certificate with its full chain from one SSLCertificateFile, with a matching key, and you have proved it from outside.
IIS serves your certificate with its private key and intermediate on an HTTPS binding with SNI, and renewed certificates get rebound instead of silently expiring.
Tomcat, or a Spring Boot or other Java server, serves your certificate with its full chain from PEM files or a PKCS #12 keystore, verified from outside.
You will have listed every certificate a server sends, checked their order and links, and verified the chain with a strict client instead of a browser.
You will have an nginx endpoint that accepts only clients holding a certificate from your own client CA, lets in only the clients you name, and is tested with curl.
You will know whether your servers and network negotiate the X25519MLKEM768 hybrid key exchange, and how to read, force and troubleshoot it with OpenSSL 3.5.
The exact messages tools and browsers print, with likely causes and safe fixes.
They run in your browser. Nothing you paste is sent anywhere.
Tool
Paste a chain and see which link is missing, expired or out of order.
Tool
Test whether a name matches a certificate's SANs and wildcards.
Tool
Paste a certificate error from any tool and get the page that explains it.
Short lessons of about nine minutes each, with check questions.
Every term in plain words, linked to its full entry.