How are the server_name and ALPN extensions carried in a TLS ClientHello, and how does the server answer each?

middleshould knowfreq 56%

answer

both offered in the first message
one name, no trailing dot, never an address
the acknowledgement repeats no name
the server selects exactly one protocol
no overlap means a fatal alert

basics

~20 s

The client offers both in its ClientHello: server_name carries one host name as a byte string, ALPN carries an ordered list of protocol identifiers. The server acknowledges server_name with an empty extension and answers ALPN with exactly one protocol it selected.

solid answer

~40 s

server_name(0) carries a list whose entry has name type host_name(0) and a HostName byte string — a DNS name, with no trailing dot, and never a literal address. application_layer_protocol_negotiation(16) carries a ProtocolNameList, the client's preference-ordered protocol identifiers. The two answers are shaped differently. For the host name the server returns an empty server_name extension: an acknowledgement that it acted on the name, not a repetition of it. For the protocol the server returns a list containing exactly one entry — its choice, made on its own preferences rather than the client's ordering. Where those answers ride depends on the version: in TLS 1.2 both are in the ServerHello, in TLS 1.3 both are in EncryptedExtensions. If no offered protocol is supported, the server must send a fatal no_application_protocol(120) alert rather than proceed with none.

`server_name(0)` carries a list whose entry has name type `host_name(0)` and a `HostName` byte string — a DNS name, with no trailing dot, and never a literal address. `application_layer_protocol_negotiation(16)` carries a `ProtocolNameList`, the client's preference-ordered protocol identifiers. The two answers are shaped differently. For the host name the server returns an **empty** `server_name` extension: an acknowledgement that it acted on the name, not a repetition of it. For the protocol the server returns a list containing **exactly one** entry — its choice, made on its own preferences rather than the client's ordering. Where those answers ride depends on the version: in TLS 1.2 both are in the `ServerHello`, in TLS 1.3 both are in `EncryptedExtensions`. If no offered protocol is supported, the server must send a fatal `no_application_protocol(120)` alert rather than proceed with none.

code

pseudocode · 18 lines

pseudocode

ClientHello
  extensions:
    server_name(0):
      ServerNameList:
        name_type = host_name(0)
        HostName  = "tickets.rail.example"
    application_layer_protocol_negotiation(16):
      ProtocolNameList = [ "h2", "http/1.1" ]

server's answer  (ServerHello in 1.2, EncryptedExtensions in 1.3)
  extensions:
    server_name(0):
      extension_data = empty        // acknowledgement only
    application_layer_protocol_negotiation(16):
      ProtocolNameList = [ "h2" ]   // exactly one, chosen by the server

if no offered protocol is supported:
  send fatal alert no_application_protocol(120) and stop

go deeper

for a junior

Know that both are offered by the client in its first message: one host name, and a list of application protocols. The server answers by acknowledging the name and naming exactly one protocol.

for a middle

Get the two answer shapes right — an empty acknowledgement for the name, a single-entry list for the protocol — and say which message carries them in each version. Mention that the server, not the client's ordering, decides.

for a senior

Handle the failure cases: no common protocol ends the handshake with a fatal alert, and a missing host name leaves a multi-name gateway selecting a default. Both surface to callers as connection failures rather than application errors.

for a principal

Consider what depends on these being visible. In TLS 1.3 both answers are protected, so any estate component that routed or reported on the selected protocol needs another source for it.

Two extensions, one message, two answer shapes

Both of these ride in the ClientHello, because both must influence what the server does before it can respond at all — a gateway serving many names cannot choose what to present until it knows which name was asked for, and a gateway speaking several application protocols cannot commit until it knows which the caller is willing to speak. What differs is the shape of the answer.

The host-name offer

The extension is server_name(0), defined for TLS in RFC 6066.
It carries a list of names, each tagged with a name type. The only name type in use is host_name(0).
The value is a HostName: a DNS host name as a byte string. No trailing dot, and not a literal address — a client connecting by address simply omits the extension.
The answer is an empty server_name extension. It repeats nothing. It means only: I received your name and acted on it.

That empty acknowledgement catches people out. There is no field in which the server confirms which name it matched, so a client learns whether the server honoured the name only from what it subsequently presents.

The protocol offer

The extension is application_layer_protocol_negotiation(16), defined in RFC 7301.
It carries a ProtocolNameList: the identifiers of the application protocols the client is willing to run, in the client's order of preference.
The answer is a list containing exactly one protocol — the one the server selected.
The server chooses. The client's ordering is an expression of preference, not an instruction, and a server is free to select any entry from the list.
If the server supports none of the offered protocols, RFC 7301 requires a fatal no_application_protocol(120) alert. The handshake ends there; it does not complete with no protocol chosen.

Where the answers ride

	TLS 1.2	TLS 1.3
Host-name acknowledgement	`ServerHello`	`EncryptedExtensions`
Selected protocol	`ServerHello`	`EncryptedExtensions`
Visible to an observer	yes	no

The move is not cosmetic. In TLS 1.3, neither answer is on the wire in readable form, so anything that used to make a routing or logging decision by reading the selected protocol out of the ServerHello has lost that input.

The failure cases worth knowing

No extension offered at all. A client that sends no protocol list gets no protocol answer, and the two sides fall back on whatever the application layer decides by other means. A server that requires the extension has to fail the connection itself; the absence of the offer is not an error in the protocol.
No protocol in common. This is the case with a defined outcome: a fatal no_application_protocol(120) alert. The connection ends during the handshake, so the calling code sees a connection failure, not an application-level error.
No host name offered. A gateway serving many names on one address then has nothing to select on and must fall back to a default, which is frequently the wrong one from the caller's point of view.

Why this pair is asked together

They are the two pieces of application context that a connection carries before the application has said anything. For a ticketing gateway that fronts several services on one address, the host name decides which configuration the connection lands in and the protocol identifier decides how the first request will be framed — both settled while the handshake is still running, both offered by the client, both answered by the server in the same message.

Version note

State the version whenever the placement of either answer matters. The extensions and their contents are identical across TLS 1.2 and 1.3; only the message that carries the server's answer, and therefore whether that answer is readable on the path, has changed.

## Two extensions, one message, two answer shapes Both of these ride in the `ClientHello`, because both must influence what the server does before it can respond at all — a gateway serving many names cannot choose what to present until it knows which name was asked for, and a gateway speaking several application protocols cannot commit until it knows which the caller is willing to speak. What differs is the **shape of the answer**. ## The host-name offer - The extension is `server_name(0)`, defined for TLS in **RFC 6066**. - It carries a list of names, each tagged with a name type. The only name type in use is `host_name(0)`. - The value is a `HostName`: a DNS host name as a byte string. **No trailing dot**, and **not** a literal address — a client connecting by address simply omits the extension. - The answer is an **empty** `server_name` extension. It repeats nothing. It means only: *I received your name and acted on it.* That empty acknowledgement catches people out. There is no field in which the server confirms *which* name it matched, so a client learns whether the server honoured the name only from what it subsequently presents. ## The protocol offer - The extension is `application_layer_protocol_negotiation(16)`, defined in **RFC 7301**. - It carries a `ProtocolNameList`: the identifiers of the application protocols the client is willing to run, in the client's order of preference. - The answer is a list containing **exactly one** protocol — the one the server selected. - **The server chooses.** The client's ordering is an expression of preference, not an instruction, and a server is free to select any entry from the list. - If the server supports **none** of the offered protocols, RFC 7301 requires a fatal `no_application_protocol(120)` alert. The handshake ends there; it does not complete with no protocol chosen. ## Where the answers ride | | TLS 1.2 | TLS 1.3 | |---|---|---| | Host-name acknowledgement | `ServerHello` | `EncryptedExtensions` | | Selected protocol | `ServerHello` | `EncryptedExtensions` | | Visible to an observer | yes | no | The move is not cosmetic. In TLS 1.3, neither answer is on the wire in readable form, so anything that used to make a routing or logging decision by reading the selected protocol out of the `ServerHello` has lost that input. ## The failure cases worth knowing 1. **No extension offered at all.** A client that sends no protocol list gets no protocol answer, and the two sides fall back on whatever the application layer decides by other means. A server that *requires* the extension has to fail the connection itself; the absence of the offer is not an error in the protocol. 2. **No protocol in common.** This is the case with a defined outcome: a fatal `no_application_protocol(120)` alert. The connection ends during the handshake, so the calling code sees a connection failure, not an application-level error. 3. **No host name offered.** A gateway serving many names on one address then has nothing to select on and must fall back to a default, which is frequently the wrong one from the caller's point of view. ## Why this pair is asked together They are the two pieces of *application* context that a connection carries **before** the application has said anything. For a ticketing gateway that fronts several services on one address, the host name decides which configuration the connection lands in and the protocol identifier decides how the first request will be framed — both settled while the handshake is still running, both offered by the client, both answered by the server in the same message. ## Version note State the version whenever the placement of either answer matters. The extensions and their contents are identical across TLS 1.2 and 1.3; only the message that carries the server's answer, and therefore whether that answer is readable on the path, has changed.

The server's server_name answer carries no name. How does a client learn which name the server actually matched?
Not from that extension — it is empty by design and acknowledges only that the offer was acted on. The client learns it from what the server goes on to present and from the identity check it performs itself. A server that matched a different name than intended produces a connection that either fails that check or succeeds for a name the caller did not ask for.
A client offers two protocols and the server prefers the second. Which is selected?
The server's. The list is ordered by the client's preference, but the specification leaves the choice to the server, which returns a list of exactly one entry. So a client cannot force a protocol by ordering; it can only decide which protocols it is prepared to accept at all.
What happens if the client offers no ALPN extension at all?
The server sends no protocol answer and the handshake completes normally. Nothing in the protocol has been agreed about the application, so the two sides fall back to whatever they would otherwise assume. A server that requires the extension has to reject the connection on its own policy; its absence is not itself a protocol error.

saying these in an interview costs you the question

Says the server echoes the requested host name back
Thinks the client's ordering decides which protocol is selected
Believes the server may return several selected protocols
Puts a literal address in the host-name extension
Assumes no common protocol just completes with none selected

How are the server_name and ALPN extensions carried in a TLS ClientHello, and how does the server answer each?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~3 min

Two extensions, one message, two answer shapes

The host-name offer

The protocol offer

Where the answers ride

The failure cases worth knowing

Why this pair is asked together

Version note

▾common follow-ups3 questions

▾red flags5 flags

Two extensions, one message, two answer shapes

The host-name offer

The protocol offer

Where the answers ride

The failure cases worth knowing

Why this pair is asked together

Version note

answer

go deeper