SSL/TLS handshake — Domainee Glossary

The negotiation at the start of every HTTPS connection where client and server agree on a cipher, exchange keys, and verify the certificate.

The TLS handshake is what happens in the first 100 milliseconds of every HTTPS connection: the client and server agree on a TLS version, negotiate a cipher suite, exchange keys, and prove the server's identity via its certificate.

TLS 1.3 handshake, simplified

Client → Server   ClientHello (supported versions, ciphers, key share)
Server → Client   ServerHello + Certificate + Finished
Client → Server   Finished + (application data)

One round trip. Application data flows on the second message.

TLS 1.2 handshake, simplified

Client → Server   ClientHello
Server → Client   ServerHello + Certificate + ServerKeyExchange + Done
Client → Server   ClientKeyExchange + ChangeCipherSpec + Finished
Server → Client   ChangeCipherSpec + Finished
Client → Server   (application data)

Two round trips. Application data flows on the third message.

Where it fails for SaaS custom domains

Three failure modes you'll see in production:

Wrong certificate served. Server has a cert for yourapp.com, but the client connected to acme.com. The browser sees a name mismatch and aborts. Fix: make sure your edge serves the right cert based on the SNI in the ClientHello.
Expired certificate. Cert was valid yesterday, expired overnight. The browser sees the dates and aborts. Fix: automate renewal at 30 days before expiry, not last-minute.
Untrusted CA. Server presents a cert signed by a CA the browser doesn't have in its trust store. Self-signed certs trip this. So do certs signed by an internal corporate CA that wasn't installed on the client. Fix: use a public CA like Let's Encrypt.

When a customer reports "SSL handshake failed," check those three first.