How SSL/TLS works: the handshake, certificates and session keys

SSL/TLS protects a connection in three moves: a quick handshake agrees fresh session keys, the server's certificate proves it really controls the domain, and those session keys then encrypt and tamper-proof everything sent. TLS is the modern successor to SSL, though "SSL certificate" is still the everyday term. It protects every HTTPS page, banking app and course app you use.

This guide walks through the TLS 1.3 handshake step by step, how certificates prove a site is genuine, and where session keys come in.

SSL or TLS? A quick history

SSL (Secure Sockets Layer) was created by Netscape in the mid-1990s. Its successor, TLS (Transport Layer Security), arrived in 1999. Every version of SSL is now retired as insecure; the last one, SSL 3.0, was formally deprecated in 2015. TLS 1.0 and 1.1 followed, with browsers dropping them around 2020. Today you should expect TLS 1.2 and, increasingly, TLS 1.3, published in 2018, which is faster and removes many older, weaker options; our comparison of TLS 1.2 and TLS 1.3 covers what changed.

So when someone says "SSL" today, they almost always mean TLS. The certificates are the same; only the old name stuck.

What TLS gives you

• Confidentiality. Nobody between you and the server, whether the Wi-Fi owner, your internet provider or anyone else on the path, can read the traffic.
  
  
• Integrity. Any change to data in transit is detected, and the connection fails rather than accept tampered data.
  
  
• Authentication. The server proves it is the genuine owner of the domain you asked for.
  
  

All three are set up in a short exchange at the start of each connection, called the handshake.

The TLS 1.3 handshake, step by step

Here's what happens in the fraction of a second after your browser has looked up a site's address and opened a connection to it:

1. Client hello. Your browser sends a greeting listing the TLS versions and encryption methods it supports, the name of the site it wants and, in TLS 1.3, its half of a fresh key exchange: a temporary public key generated just for this connection.
   
   
2. Server hello. The server chooses the encryption method and replies with its own temporary public key. Each side combines its private half with the other's public half and arrives at the same shared secret, using Diffie-Hellman key exchange. Someone who recorded both messages still can't work it out.
   
   
3. Everything is encrypted from here on. The server sends its certificate chain, protected with keys derived from that secret. In TLS 1.2, the certificate travelled unencrypted.
   
   
4. Proof of ownership. Certificates are public, so anyone could send a copy of one. The server therefore signs a summary of the whole handshake with the private key that matches its certificate, proving it holds that key.
   
   
5. Finished. The server sends a check value computed over every handshake message, so both sides can confirm nothing was altered in transit.
   
   
6. The browser checks everything. It verifies the certificate chain, the domain name, the validity dates and the signature, then sends its own "finished" message.
   
   
7. Your request goes out, encrypted with fresh session keys.
   
   

The whole exchange costs one round trip. The browser says hello with its key share; the server answers with its key share, certificate, proof and finished message in one go; the browser finishes and sends its request straight away. TLS 1.2 needed two round trips before any data could flow, and on a slow mobile connection every round trip adds noticeable delay.

Returning visitors can go further. With session resumption, a browser can send data in its very first message, a feature known as 0-RTT. The catch is that this "early data" can be replayed by an attacker, so servers should accept it only for requests that are harmless to repeat.

Certificates: how your browser knows it's the real site

A TLS certificate is a digital document that binds a domain name to a public key. It lists the domain names it covers, the public key, the issuer and the validity dates, and it carries the issuer's digital signature.

A passport is a useful comparison. It is issued by an authority others trust, after checks. But a photocopy of a passport proves nothing on its own, because anyone can make one. What counts is that the person presenting it matches the photo. In TLS, the certificate is the passport, and the server's signature with its private key, step 4 above, is the face that matches.

The chain of trust

Browsers don't know every website's certificate in advance. Instead, they rely on a public key infrastructure:

1. the website's certificate is signed by an intermediate certificate authority (CA);
   
   
2. the intermediate is signed by a root CA;
   
   
3. root certificates come pre-installed in your operating system or browser, whose makers vet the CAs they include.
   
   

Your browser follows the signatures up the chain until it reaches a root it already trusts. If a link is missing, expired or wrongly signed, you see a warning page instead of the site.

How CAs decide who gets a certificate

For most sites, the CA only checks that the applicant controls the domain, for example by asking them to publish a specific file on the website or a specific record in its DNS settings. This is automated through a protocol called ACME, which is how free CAs such as Let's Encrypt issue and renew certificates in seconds. Browsers such as Chrome and Safari also require publicly trusted certificates to be recorded in public Certificate Transparency logs, so domain owners can spot any certificate issued for their domain without their knowledge.

Certificate lifetimes are getting shorter

Checking whether a certificate has been revoked has never worked reliably, so the industry is limiting how long any certificate can live instead. Under a schedule agreed by the CA/Browser Forum, the maximum lifetime of a public TLS certificate fell from 398 days to 200 days in March 2026, and is due to fall to 100 days in March 2027 and 47 days in March 2029. The message for site owners is simple: automate renewal, because manual renewal won't keep up.

Session keys and forward secrecy

The certificate's private key is used only to prove identity. It doesn't encrypt your data. That job belongs to session keys, derived from the shared secret agreed during the handshake:

• separate keys are derived for each direction of traffic, and separate keys again for the handshake and for application data;
  
  
• data is encrypted with fast symmetric ciphers, usually AES-GCM or ChaCha20-Poly1305, which also detect tampering, as our guide to cipher suites explains;
  
  
• the temporary key-exchange values are thrown away after use.
  
  

That last point gives TLS 1.3 forward secrecy. Even if a server's private key is stolen years later, an attacker who recorded old traffic can't decrypt it, because the secrets needed were never sent and no longer exist. Older setups that used RSA to send the secret directly lacked this property, which is one reason TLS 1.3 removed that option.

Key exchange is also being upgraded for the quantum era. Current versions of Chrome, Firefox and Safari, along with major CDNs, combine the classic elliptic-curve exchange with ML-KEM, a post-quantum algorithm standardised by NIST, so traffic recorded today stays safe even if large quantum computers arrive later. Our guide to post-quantum cryptography covers the timeline.

What TLS doesn't hide or protect

• Which site you're visiting. The site name is usually visible in the client hello and in DNS lookups. A recently standardised extension, Encrypted Client Hello (ECH), hides it, but support is still rolling out.
  
  
• Traffic patterns. IP addresses, timing and data volumes remain visible.
  
  
• The endpoints. TLS protects the pipe. It can't help if the device has malware or the server has been compromised.
  
  
• Honesty. Phishing sites get valid certificates too. A secure connection means you're talking privately to the site in the address bar, not that the site is trustworthy, a point our guide to what HTTPS means returns to.
  
  

Common TLS problems for site owners

• Expired certificates remain a frequent cause of outages. Automate renewal and monitor expiry dates.
  
  
• Incomplete chains. If the server doesn't send its intermediate certificate, some clients, older Android devices in particular, fail even when desktop browsers work.
  
  
• Old protocol versions left switched on. Disable TLS 1.0 and 1.1.
  
  
• Name mismatches, such as a certificate that covers www.example.com but not example.com.
  
  
• Wrong clocks. A phone whose date is badly wrong will reject perfectly valid certificates, which is worth remembering when a student reports a "connection not private" error.
  
  

Key takeaways

• TLS is the modern successor to SSL, and it provides confidentiality, integrity and authentication.
  
  
• The TLS 1.3 handshake takes one round trip: exchange key shares, prove identity, confirm, then send data.
  
  
• Certificates bind a domain to a public key, and a chain of signatures links them to roots your device already trusts.
  
  
• Session keys are fresh for every connection, and forward secrecy protects past traffic even if a server's key leaks later.
  
  
• Certificate lifetimes are shrinking fast, so automated renewal is now essential.
  
  

TLS is a remarkable piece of engineering. In a fraction of a second, two computers that have never met agree on secret keys, verify an identity through a chain of signatures and set up a private channel. Understanding those moving parts makes it much easier to diagnose certificate errors, configure servers well and ask the right questions about how your data travels.

Frequently asked questions

Is SSL the same as TLS?

TLS is the successor to SSL. Every version of SSL has been retired as insecure, and modern connections use TLS 1.2 or TLS 1.3. The old name stuck, so people still say "SSL certificate" and "SSL error", but the certificates are the same and the protocol actually running is TLS. When a host or vendor says SSL today, they almost always mean TLS.

What happens during the TLS handshake?

In TLS 1.3, the browser sends a hello with its half of a key exchange; the server replies with its half, its certificate, a signature proving it holds the certificate's private key, and a check value over the handshake. Both sides derive the same session keys, the browser verifies the certificate chain and domain, and encrypted data starts flowing, all within one round trip.

What is a TLS certificate?

A TLS certificate is a digital document that binds a domain name to a public key. It lists the domains it covers, the key, the issuer and its validity dates, and it is signed by a certificate authority that browsers trust. During the handshake, the server proves it holds the matching private key, so a copied certificate alone is useless to an impostor.

What is forward secrecy in TLS?

Forward secrecy means that stealing a server's private key later doesn't expose traffic recorded earlier. TLS 1.3 achieves it by agreeing fresh, temporary key-exchange values for every connection and throwing them away afterwards. The certificate's private key only proves identity; it never encrypts the session keys, so there is nothing for an attacker to decrypt with it later.