Short answer: A certificate-authenticated TLS handshake negotiates parameters, proves the server's identity, and derives encryption keys. A typical full TLS 1.2 exchange takes two round trips; TLS 1.3 commonly takes one. Those counts exclude TCP setup and have resumption and retry exceptions.
Before this: symmetric and asymmetric encryption and certificate chains.
What the handshake has to accomplish
Meeting a new business contact for the first time means checking their credentials, agreeing on which shared rules you'll both follow, and settling on a private code only the two of you know before discussing anything sensitive. TLS (Transport Layer Security) does exactly that, in three jobs: agree on a protocol version and cipher suite, authenticate the server using the certificate chain from PKI & Digital Certificates, and establish shared symmetric session keys. That last part is hybrid encryption in action: asymmetric crypto is used only to set the session keys up, then fast symmetric encryption handles the actual data for the rest of the connection.
TLS 1.2: Two round trips
The ordinary full TLS 1.2 handshake shown here uses ephemeral elliptic-curve Diffie-Hellman (ECDHE) with server certificate authentication and no client certificate. It takes two round trips before the client can send application data after verifying the server's Finished. Resumption and the optional False Start optimization change this timing. In the business meeting analogy, the first exchange checks credentials and rules; the second confirms both parties derived the private code.
What's actually on the wire, message by message
The diagram above shows the shape of the conversation. Here's what's actually inside each flight; expand any of them.
ClientHello client → server, plaintext
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, in preference orderServerHello server → client, plaintext
Certificate, ServerKeyExchange, ServerHelloDone server → client, plaintext
Sent as one flight, back to back.
ClientKeyExchange, ChangeCipherSpec, Finished client → server
0x01: "everything after this is encrypted with the keys we just derived"ServerChangeCipherSpec, Finished server → client
How the session keys actually get derived math, not wire bytes
Nothing sent so far is the actual encryption key. Both sides separately compute it from what was exchanged, and never transmit it.
TLS 1.3: One round trip, sometimes zero
TLS 1.3 commonly includes the client's key_share in ClientHello. If the server accepts the offered group, the client can verify the server's first flight and send Finished plus application data after one round trip. A HelloRetryRequest adds a round trip when another key share is needed. The business contact arrives with a proposed key-agreement method instead of asking which one to prepare. Messages after ServerHello are encrypted with handshake keys, before application traffic keys take over.
What's actually on the wire, message by message
ClientHello client → server, plaintext
TLS_AES_128_GCM_SHA256, TLS_CHACHA20_POLY1305_SHA256ServerHello server → client, plaintext, the last unencrypted message
EncryptedExtensions, Certificate, CertificateVerify, Finished server → client, encrypted
These TLS 1.3 server messages use handshake keys derived after ServerHello. They are not a one-for-one rearrangement of TLS 1.2 messages. In particular, EncryptedExtensions and server CertificateVerify have distinct TLS 1.3 roles.
Finished client → server, encrypted
The client's proof authenticates its view of the transcript and confirms the handshake keys. Application traffic uses separate keys. The server can send application data after its own Finished, before receiving the client's Finished; it must not treat the client as authenticated before verification where client authentication is required.
0-RTT early data optional, requires a suitable PSK
With a suitable PSK (Pre-Shared Key), commonly from a previous session ticket, the client may send early application-data records alongside ClientHello, not inside that handshake message. The server may reject early data. It lacks forward secrecy and can be replayed, so application-level replay safety matters. A method named GET is not by itself proof that replay is harmless. The handshake still completes; 0-RTT describes when eligible early data can be sent.
| Property | TLS 1.2 | TLS 1.3 |
|---|---|---|
| Typical full handshake, excluding TCP | Two RTTs | One RTT without HelloRetryRequest; optional 0-RTT early data has separate rules |
| Cipher selection | Broader suite set; current security guidance excludes weak choices | AEAD suites only; static RSA key transport and CBC suites removed |
| Forward secrecy | Depends on key exchange, such as ECDHE | Provided by ephemeral (EC)DHE; PSK-only mode and 0-RTT do not provide it |
Worked example: negotiation is not identity
In an illustrative TLS 1.3 connection to portal.example, the client offers supported_versions = 0x0304 and an X25519 key_share. The server selects TLS_AES_128_GCM_SHA256 and returns its key share. This cipher-suite name selects record encryption and the key-schedule hash; it does not select X25519 or the certificate signature algorithm.
The client still has to validate a trusted certificate chain, check certificate validity, match the requested DNS name against the certificate's subjectAltName, and verify CertificateVerify and Finished. Agreeing on a private code with the business contact does not establish their identity until the credentials are checked. A passive TLS 1.3 capture can show the hellos but cannot normally read the encrypted certificate flight without session secrets.
| Failure | Check | Interpretation |
|---|---|---|
| Hostname mismatch | Compare requested hostname, SNI, and certificate subjectAltName | Reaching a server and negotiating encryption do not prove it is the intended server. |
| Unknown issuer or incomplete chain | Inspect the presented intermediates and the client's trust store | A locally trusted root may be absent on another device. Disabling verification hides the problem. |
| Protocol or handshake failure | Inspect client/server logs and supported versions, groups, and signature algorithms | A generic alert is not enough to identify which negotiation or policy check failed. |
| Expired or not-yet-valid certificate | Check certificate dates and the client's clock | Clock error and actual expiry can produce similar symptoms. |
TLS still assumes a reliable, ordered byte stream underneath it, which is exactly what TCP provides. That's true for TLS 1.2 and 1.3 alike. QUIC, the transport HTTP/3 uses (see HTTP/HTTPS: 1.1 vs 2 vs 3), handles this differently by folding TLS 1.3 directly into its own transport instead of layering it on top of TCP.
Related topics and sources
Connect this to TCP connection setup and HTTP/2 and HTTP/3.