TLS explained: what happens before the padlock appears

What TLS actually provides

Three properties, separated here because they fail separately.

• Confidentiality

  What travels between the two sides is unreadable to anybody in the path. This is the property people mean when they say encrypted, and it is the least interesting of the three, because it is also the easiest to have without the others.

• Integrity

  Nothing in transit can be altered without both sides noticing. Encryption alone would not give you this: an attacker unable to read a message can still corrupt it, and integrity is what makes that detectable rather than silent.

• Authentication of the server

  You are talking to the name you asked for, rather than to somebody who arranged to be in the middle. This is the property certificates exist to establish, and it is the one that fails most visibly, because a browser refuses to continue without it.

Confidentiality without authentication is the dangerous combination: a perfectly encrypted connection to the wrong party protects that party's conversation with you.

The order of events

Four stages, always in this order, and knowing which one you are in narrows every diagnosis.

• A connection opens

  Ordinary networking, before any encryption exists. Failures here are network failures and look nothing like certificate problems.

• The handshake runs

  Both sides state what they support, agree on parameters, and establish keys. Nothing is encrypted yet at the start of this and everything is by the end.

• The server presents its certificate

  The client checks it against the name it asked for, the dates it carries, and the chain behind it. This is where a browser warning comes from.

• Application data flows

  Your request finally leaves, encrypted. A failure at this stage is your application's, not the protocol's.

What the handshake settles

Four questions, answered in one exchange.

• Which protocol version

  Both sides support several and use the highest they share. Where they share none, the connection ends before anything else, which is one of the two ways a handshake fails for everyone at once.

• Which cipher suite

  The specific combination of algorithms used for the rest of the conversation, chosen from what both sides offer.

• Which name is being requested

  A single address can serve many names, so the client states which one it wants early enough for the server to present the matching certificate. Without this, a server could only ever hold one certificate per address.

• The keys themselves

  Derived rather than transmitted, which is why somebody recording the exchange cannot reconstruct them afterwards from what they captured.

Why the details keep changing

The protocol is not stable in the way its name suggests, and understanding why saves you from configuration advice that has quietly expired.

Cipher suites are removed when weaknesses are found, which means a list that was correct when somebody wrote it becomes a liability years later without anything on your server changing. Protocol versions are withdrawn by browsers on their own schedules, so a server that worked yesterday can start failing for visitors whose browser updated overnight.

The practical consequence is that configuration copied from an article is the single most common way to end up with something worse than the default. Defaults are maintained by people tracking these changes; a block of text in a document is not.

Where each failure appears

The stage decides the symptom, which is why the same underlying fault produces different messages in different browsers.

• No shared version or suite, and the connection ends immediately for

everybody. Covered on SSL handshake failed.

• **The certificate does not match, has expired, or cannot be traced to

something trusted.** These are the visible warnings, and they are sorted by code on SSL errors.

• The chain is incomplete, which fails for some clients and not others,

because browsers are more forgiving than libraries. The mechanism is on certificate chains.

What this section covers

The pages below take the protocol apart step by step: the handshake stage by stage, what changed between protocol versions, how to read a cipher suite rather than memorise a list, how keys are exchanged, why compromising a key today does not expose yesterday's traffic, how sessions are resumed and what that costs, how the application protocol is negotiated, what early data buys and risks, how downgrade attempts are refused, and what a client actually checks before accepting a certificate.

What belongs elsewhere

Three boundaries, so this section stays about the protocol.

• Certificates as objects

  belong to certificates: what one contains, what validation levels verify, and how the lifecycle runs. Here they appear only as something the handshake presents.

• Browser errors

  belong to SSL errors, which sorts them by the code on screen. This section explains the mechanism behind a failure rather than helping you find yours.

• Single-term definitions

  belong in the glossary. A page here explains how something works and what breaks; a glossary entry answers what a word means and sends you onward.

FAQ