skip to content

In TLS, where does a stapled certificate status response travel, and which extension asks the server for one?

level: middleimportance: nice to knowfreq 30%

answer

  1. the client asks first
  2. a request, not an obligation
  3. 1.2 sends a separate message
  4. 1.3 attaches it per entry
  5. status_request(5) in the ClientHello

basics

~20 s

The client asks with status_request(5) in its ClientHello. TLS 1.2 answers with a separate CertificateStatus handshake message after Certificate; TLS 1.3 carries the response as an extension inside the CertificateEntry it describes, so any entry in the chain can carry one.

solid answer

~40 s

Stapling is a carriage mechanism, and the carriage moved between versions. The client asks by sending `status_request(5)` in its `ClientHello`. In TLS 1.2 a server that has a response sends it as a separate `CertificateStatus` handshake message immediately after `Certificate` — one message, in practice describing the end-entity certificate only. In TLS 1.3 the response instead rides as an extension inside the `CertificateEntry` it refers to, which means each certificate in the `certificate_list` can carry its own status and no extra handshake message is needed. Either way the extension is a request, not an obligation: a server with nothing to staple sends nothing and the handshake continues, unless the client has been told to require one.

code

pseudocode · 15 lines
pseudocode
# the ask, identical in both versions
ClientHello
  extensions: status_request(5)

# TLS 1.2 answer
Certificate(11)
  certificate_list: [ end-entity, intermediate ]
CertificateStatus            # separate message, describes one certificate

# TLS 1.3 answer
Certificate(11)
  certificate_list:
    entry[0] end-entity   extensions: status_request(5) -> response
    entry[1] intermediate extensions: status_request(5) -> response
# no separate message in the flight

go deeper

for a junior

Hold the shape: the client asks for a status alongside the certificate, and the server attaches one if it has it. Nobody fetches anything separately in the common case.

for a middle

Name the extension and both carriage points, and be able to say that the TLS 1.3 form is per-certificate while the TLS 1.2 form was a single separate message.

for a senior

When nothing is stapled, work the carriage causes in order: the client may not have asked, the server may have nothing, or the check may be looking for the wrong version's shape.

for a principal

Decide whether to depend on stapling at all, given that its presence is best-effort on every connection, and say what the fallback path costs in latency and in failed connections.

## Who asks, and with what Stapling begins on the client side. The client includes `status_request(5)` in its `ClientHello`, which says "if you have a status response for the certificate you are about to send, include it". The point of the arrangement is that the server, which is going to be in the conversation anyway, supplies the evidence rather than each client independently going off to fetch it. The extension is a **request**. Nothing in it obliges the server to produce anything. ## Where the answer rides, by version | | TLS 1.2 | TLS 1.3 | |---|---|---| | Client asks with | `status_request(5)` in `ClientHello` | `status_request(5)` in `ClientHello` | | Server answers in | a separate `CertificateStatus` handshake message | an extension inside a `CertificateEntry` | | Position in the flight | immediately after `Certificate` | inside `Certificate`, per entry | | How many certificates can be covered | one, in practice the end-entity certificate | any entry in the `certificate_list` | | Extra handshake message | yes | no | That is the whole delta, and it is the part of stapling that belongs to the wire rather than to revocation policy. ## Why TLS 1.3 moved it The TLS 1.2 shape has a structural limit: one standalone message describing one certificate. If an intermediate also has a status worth attaching, there is nowhere to put it. TLS 1.3 gave every `CertificateEntry` its own extension block, which turns the question into a per-certificate one: - a status can accompany the end-entity certificate, an intermediate, or both; - the association between a response and the certificate it describes is positional and unambiguous — it is attached to the entry; - one message disappears from the flight, since nothing needs to be sent separately. This is a good illustration of a general TLS 1.3 move: data that used to need its own message becomes an extension on the structure it belongs to. ## What the mechanism does and does not settle - It **does** decide where bytes travel and who asks for them. - It **does** remove a separate lookup from the client's critical path when a response is present. - It **does not** make the response trustworthy, current, or sufficient — whether a status is fresh enough, what it asserts, and what a client should do when it is missing are revocation questions, not carriage questions. - It **does not** guarantee a response exists. A server with nothing to attach simply attaches nothing. - It **does not** change certificate selection. The certificate is chosen first; the status is attached to what was chosen. ## The failure shape worth recognising The common report is "stapling is configured but nothing is stapled". Read in carriage terms, that has a small number of causes: 1. The client never sent `status_request(5)`, so the server had no reason to attach anything. Not every client asks. 2. The server has no response available to attach at that moment, so it sends the chain unaccompanied. 3. The observer is looking in the wrong place for the version in use — checking for a separate `CertificateStatus` message on a TLS 1.3 connection, where the response is inside the `Certificate` message instead. Cause 3 is a pure version-confusion bug in the *diagnosis*, and it is common precisely because the older shape is the one most documentation describes. ## Boundaries Everything about the content of a status response — what it asserts, how long it stays acceptable, what a client should do when one does not arrive, and whether a certificate can demand that one always does — is revocation material and sits outside the wire slice. What belongs here is narrow and worth being exact about: the client asks with `status_request(5)`, TLS 1.2 answers in `CertificateStatus`, and TLS 1.3 answers inside the `CertificateEntry`.

  • Why did TLS 1.3 move the response out of its own message and into the CertificateEntry?
    Because a single standalone message can only sensibly describe a single certificate, and in practice that meant the end-entity one. Attaching the response to the entry it refers to makes the association positional and lets any certificate in the `certificate_list` carry its own status. It also removes a message from the flight, which is the same consolidation TLS 1.3 applied in several other places.
  • Is the server obliged to attach a response when the client sends status_request(5)?
    No. The extension asks; it does not compel. A server that has no response available sends the chain without one and the handshake continues normally. The exception is a client that has been configured or otherwise told to require a stapled response, which may then refuse — but that requirement comes from policy about revocation, not from the carriage mechanism itself.

saying these in an interview costs you the question

  • Thinks the server staples without the client asking
  • Says TLS 1.3 still uses a separate CertificateStatus message
  • Assumes a stapled response can only ever describe the end-entity certificate
  • Confuses the request extension with a certificate's own extensions
  • Believes a missing stapled response always aborts the handshake