TLS handshake sequence
Client and server establishing an encrypted connection.
HTTPS feels simple — you click a link and the page loads — but every secure connection begins with a silent conversation called the TLS handshake. In just a handful of messages, the client and server agree on encryption, verify the server is who it claims to be, and derive a shared session key. Getting that flow right is the difference between a secure service and one that leaks credentials.
This template shows the handshake in 11 steps: the hello messages where both sides announce their capabilities, the server's certificate, the client's verification that the certificate is real (by checking the CA's signature), the exchange of the premaster secret, and the derivation and confirmation of the session key.
When to use this template
- Security architecture reviews — visually walk through where TLS termination happens and which parties hold which keys.
- Incident post-mortems — when a certificate expires or a hostname mismatch breaks production, this diagram lets you trace exactly where the check should have happened.
- Onboarding engineers into infrastructure — new team members often don't realize the handshake happens for every HTTPS connection. Seeing the message count and the CA verification step makes the cost and the benefit obvious.
How to adapt it
Start by adding the specific details of your implementation:
- Replace the generic CA with your actual certificate provider (Let's Encrypt, DigiCert, your internal PKI).
- Add a stapling step where the server includes a cached OCSP response proving the certificate hasn't been revoked.
- For client certificates, insert a mirror flow where the server also requests and validates the client's certificate after ServerHello.
Visual edits to this diagram regenerate clean Mermaid code, so you can copy the result straight into your security documentation or architecture review notes.
Mermaid code
Copy it anywhere Mermaid is supported — GitHub, Notion, or your docs.
sequenceDiagram
participant Client
participant Server
participant CA as Certificate Authority
Client->>Server: ClientHello (supported ciphers, TLS version)
Server->>Client: ServerHello (chosen cipher, TLS version)
Server->>Client: Certificate (public key + chain)
Client->>CA: Verify certificate signature
CA-->>Client: Valid
Client->>Server: ClientKeyExchange (encrypted premaster secret)
Client->>Client: Derive session key
Server->>Server: Derive session key
Client->>Server: Finished (encrypted)
Server->>Client: Finished (encrypted)
Client->>Server: Encrypted application data
Frequently asked questions
- What is a TLS handshake?
- It's the negotiation between a client (usually a browser) and a server where they agree on encryption settings, verify each other's identity via certificates, and derive a shared session key. All of this happens before any application data (your web page, API response) is sent, which is why HTTPS feels slightly slower than HTTP.
- Why do we need a Certificate Authority in the TLS handshake?
- The CA is the trusted third party that signs the server's certificate with its own private key. When the client checks the signature, it proves the certificate is real — the server actually owns that domain — not a forgery by an attacker sitting between you and the internet.
- What is the premaster secret?
- It's a random value the client generates, encrypts with the server's public key, and sends. Only the server can decrypt it because only the server has the matching private key. Both sides then use this premaster secret to derive the session key they'll use for the rest of the conversation.
- How do I adapt this for mutual TLS or certificate pinning?
- For mutual TLS (mTLS), add a step after ServerHello where the server also requests and validates the client's certificate — two extra exchanges mirroring the server's flow. For certificate pinning, document a validation step in the client where it checks that the server's certificate matches a pinned hash before proceeding — that becomes visible as a decision diamond if you convert this to a flowchart.