TLS/SSL Handshake, Step by Step

Why this matters

"The site is showing a certificate error" is one of the most common alarms a support engineer sees, and it's almost never actually about encryption strength — it's about trust, timing, or configuration. Understanding the handshake means you can tell, from the specific error message alone, roughly which of those three it is.

What you'll learn

The five-step handshake sequence, why certificate expiry causes a hard failure rather than a warning, and the specific commands to inspect a certificate's actual state instead of guessing from a browser error message.

The handshake, step by step

1. Client Hello — the browser tells the server which TLS versions and cipher suites it supports, and sends a random value used later for key generation.
2. Server Hello — the server picks a TLS version and cipher suite from what the client offered, and sends back its own random value plus its certificate.
3. Certificate verification — the client checks the server's certificate: is it signed by a certificate authority the client already trusts, is the hostname it was issued for a match, and — critically — is today's date within the certificate's valid period.
4. Key exchange — client and server use the exchanged random values (and the server's public key from its certificate) to independently derive the same shared symmetric encryption key, without ever sending that key itself over the network.
5. Finished — both sides confirm the handshake succeeded and switch to encrypted communication using the newly shared key for the rest of the session.

All of this happens before a single byte of the actual HTTP request is sent — which is why a broken certificate blocks the connection entirely rather than degrading gracefully.

Why expired certificates fail hard, not softly

A certificate has a fixed valid-from and valid-until date, checked in step 3 above. There's no partial-trust state — a certificate is either within its valid window or it isn't. The moment the clock crosses the expiry timestamp, every client independently and simultaneously starts rejecting the handshake, which is why certificate expiry incidents tend to look like "everything broke at once" rather than a gradual degradation. This is also why certificate renewal should never be a manual, easy-to-forget process for anything production-facing — automated renewal (like ACME/Let's Encrypt) exists specifically to remove the human "did anyone remember" step.

Reading a certificate yourself instead of trusting the browser's summary

openssl s_client -connect iamravi.com:443 -servername iamravi.com
openssl s_client -connect iamravi.com:443 -servername iamravi.com < /dev/null | openssl x509 -noout -dates

The first command opens a live connection and dumps the full handshake detail, including the entire certificate chain. The second extracts just the validity dates (notBefore/notAfter) — the fastest way to confirm "is this actually an expiry problem" without wading through the full chain output. On Windows, a browser's padlock-icon certificate viewer shows the same dates without needing openssl installed.

What's next

If you're seeing a certificate error right now, check the dates first using the command above before assuming it's anything more complex. For the layer just before TLS in the request lifecycle, see How DNS Resolution Actually Works; for the layer just after, see HTTP Status Codes You'll Actually See in Production.

Part of: Freshers, Sitecore Engineers

Mark this article as read

← Back to Guides

Next → What Computer Science Actually Is (and What It Isn't) An honest picture of what a computer science degree really is before you start — problem-solving over memorization, why it's not just 'learning to code', and how to set the right expectations for four years.