In a TLS 1.3 handshake, what does the point in the flight at which an alert arrived rule out about its cause?

seniormust knowfreq 55%

answer

a triple, not a description
order eliminates, it does not select
no Certificate yet, no certificate verdict
protected record implies an author
TLS 1.2 keeps the order, loses the protection

basics

~20 s

Position eliminates causes. An alert arriving before any Certificate has been sent cannot be a verdict on a certificate, and one that arrives as a protected record came from the peer that completed the key exchange rather than from anything on the path.

solid answer

~50 s

A description alone is half a symptom; the useful unit is description plus direction plus position. Before ServerHello, only the ClientHello has been seen, so an alert there can only be a verdict on what the client offered - versions, groups, suites, signature algorithms, extensions, the host_name - and it cannot be about a certificate, because none has been sent. After ServerHello the records are protected under handshake traffic keys, so an alert you received as a protected record was produced by the peer that completed the key exchange; something sitting on the path with no keys did not read it and did not write it. A certificate verdict from the client can only follow Certificate and CertificateVerify being processed, and a decrypt_error(51) at the point Finished is checked points at a signature or Finished verification rather than at any certificate's contents.

A description alone is half a symptom; the useful unit is description plus direction plus position. Before `ServerHello`, only the `ClientHello` has been seen, so an alert there can only be a verdict on what the client offered - versions, groups, suites, signature algorithms, extensions, the `host_name` - and it cannot be about a certificate, because none has been sent. After `ServerHello` the records are protected under handshake traffic keys, so an alert you received as a protected record was produced by the peer that completed the key exchange; something sitting on the path with no keys did not read it and did not write it. A certificate verdict from the client can only follow `Certificate` and `CertificateVerify` being processed, and a `decrypt_error(51)` at the point `Finished` is checked points at a signature or Finished verification rather than at any certificate's contents.

code

pseudocode · 14 lines

pseudocode

function narrow_cause(alert_description, arrival_point, was_protected):
    if arrival_point is before ServerHello:
        exclude every certificate verdict
        consider versions, groups, suites, signature algorithms, extensions

    if arrival_point is after ServerHello and was_protected:
        conclude sender held the handshake traffic keys
        exclude an on-path device as the author

    if alert_description is decrypt_error(51) at Finished:
        consider a handshake signature or Finished value that failed
        exclude the certificate's own contents

    return remaining causes

go deeper

for a junior

Hold on to the ordering rule: a peer cannot pass judgment on a certificate before one has been sent, so an early alert is always about what the client offered.

for a middle

Explain what has crossed the wire at each point of the flight and what that makes impossible, and know that after ServerHello the records are protected under handshake traffic keys.

for a senior

Demonstrate the triple - description, direction, position - and use it to eliminate. Say which hypotheses a protected alert kills, and be explicit that the protection argument is a TLS 1.3 one.

for a principal

The lead's version is about evidence quality: whether your systems capture direction and position at all, since a description logged alone routinely costs an incident an hour of guesswork it did not need.

Description, direction, position

Every good TLS failure report is a triple: which description arrived, which peer sent it, and where in the flight it arrived. Most reports carry only the first, which is why most investigations start too wide. The third is often the most eliminating of the three, because a TLS handshake is strictly ordered - a peer cannot have an opinion about something it has not received yet.

Before ServerHello

At this point exactly one message has crossed: the ClientHello. An alert here can only be a verdict on what that message offered:

the versions in supported_versions(43);
the groups and shares in key_share(51);
the cipher suites listed;
the algorithms in signature_algorithms(13);
the extensions present or absent, including the host_name in server_name(0).

What it cannot be is a verdict on a certificate. No Certificate message exists yet, so a bad_certificate(42) or certificate_expired(45) at this point is impossible - and if an application reports one, the application is summarising something else it decided locally, not relaying the peer.

One more caution: alerts this early travel unprotected, so they establish less about their author than later ones do.

After ServerHello: a protected alert has an author

Once ServerHello has been sent, the remaining handshake messages - EncryptedExtensions, CertificateRequest, Certificate, CertificateVerify, Finished - and any alerts alongside them travel protected under handshake traffic keys.

That gives the position real evidential weight: an alert you received as a protected record was produced by the peer that completed the key exchange. A device on the path that holds none of those keys neither read it nor produced it. So "the alert says the certificate expired, but something in the middle must be interfering" is a hypothesis the position has already refused.

Three arrivals, three eliminations

A handshake_failure(40) immediately after the ClientHello. Certificates are out. Whatever was unacceptable, it was in the offer - and since no HelloRetryRequest was attempted, the peer did not even see a path worth retrying.
A bad_certificate(42) after CertificateVerify. Negotiation succeeded: a version, a suite and a group were agreed, and the client got far enough to validate. The cause is in what the peer presented or in what the validator trusts.
A decrypt_error(51) where Finished is processed. This is a handshake cryptographic operation failing - a signature or a Finished value that did not verify. It is not a statement about a certificate's contents, even though a certificate was involved in producing the signature.

What TLS 1.2 changes

The ordering logic still applies - a peer cannot judge a certificate before receiving one - but the protection does not. In TLS 1.2 the server's Certificate message and the handshake alerts around it are not protected, so the same alert arriving at the same point tells you much less about who wrote it. Say which version you are reasoning about; the elimination you can make depends on it.

What position never tells you

Which of several possible causes at that point applies. Position narrows the set; it does not pick a member.
Whether the peer chose to be vague. A peer may send the catch-all at any point it likes.
That nothing on the path is involved at all. It tells you that this alert came from the peer holding the keys. An intermediary can still have shaped the exchange earlier, when everything was in the clear.

Why interviewers reach for this

Because it separates two kinds of candidate cleanly. One reads the description and starts changing configuration. The other asks where it arrived and which side sent it, and has removed most of the search space before touching anything. The second habit is what the question is for.

## Description, direction, position Every good TLS failure report is a triple: **which description** arrived, **which peer sent it**, and **where in the flight it arrived**. Most reports carry only the first, which is why most investigations start too wide. The third is often the most eliminating of the three, because a TLS handshake is strictly ordered - a peer cannot have an opinion about something it has not received yet. ## Before ServerHello At this point exactly one message has crossed: the `ClientHello`. An alert here can only be a verdict on what that message offered: - the versions in `supported_versions(43)`; - the groups and shares in `key_share(51)`; - the cipher suites listed; - the algorithms in `signature_algorithms(13)`; - the extensions present or absent, including the `host_name` in `server_name(0)`. What it **cannot** be is a verdict on a certificate. No `Certificate` message exists yet, so a `bad_certificate(42)` or `certificate_expired(45)` at this point is impossible - and if an application reports one, the application is summarising something else it decided locally, not relaying the peer. One more caution: alerts this early travel unprotected, so they establish less about their author than later ones do. ## After ServerHello: a protected alert has an author Once `ServerHello` has been sent, the remaining handshake messages - `EncryptedExtensions`, `CertificateRequest`, `Certificate`, `CertificateVerify`, `Finished` - and any alerts alongside them travel protected under handshake traffic keys. That gives the position real evidential weight: **an alert you received as a protected record was produced by the peer that completed the key exchange**. A device on the path that holds none of those keys neither read it nor produced it. So "the alert says the certificate expired, but something in the middle must be interfering" is a hypothesis the position has already refused. ## Three arrivals, three eliminations 1. **A `handshake_failure(40)` immediately after the `ClientHello`.** Certificates are out. Whatever was unacceptable, it was in the offer - and since no `HelloRetryRequest` was attempted, the peer did not even see a path worth retrying. 2. **A `bad_certificate(42)` after `CertificateVerify`.** Negotiation succeeded: a version, a suite and a group were agreed, and the client got far enough to validate. The cause is in what the peer presented or in what the validator trusts. 3. **A `decrypt_error(51)` where `Finished` is processed.** This is a handshake cryptographic operation failing - a signature or a Finished value that did not verify. It is not a statement about a certificate's contents, even though a certificate was involved in producing the signature. ## What TLS 1.2 changes The ordering logic still applies - a peer cannot judge a certificate before receiving one - but the protection does not. In TLS 1.2 the server's `Certificate` message and the handshake alerts around it are not protected, so the same alert arriving at the same point tells you much less about who wrote it. Say which version you are reasoning about; the elimination you can make depends on it. ## What position never tells you - **Which of several possible causes at that point applies.** Position narrows the set; it does not pick a member. - **Whether the peer chose to be vague.** A peer may send the catch-all at any point it likes. - **That nothing on the path is involved at all.** It tells you that *this* alert came from the peer holding the keys. An intermediary can still have shaped the exchange earlier, when everything was in the clear. ## Why interviewers reach for this Because it separates two kinds of candidate cleanly. One reads the description and starts changing configuration. The other asks where it arrived and which side sent it, and has removed most of the search space before touching anything. The second habit is what the question is for.

An application logs a certificate error, but the exchange ended before any Certificate message was sent. What happened?
The peer did not say that. Something local produced the wording - a pre-flight check, a cached decision, or a generic message attached to any failure - and the wire says only that the exchange ended during negotiation. Trust the ordering over the wording: no Certificate message means no certificate verdict from the peer, so the cause is in what the client offered.
Why does a protected alert make an on-path explanation weaker?
Because producing one requires the handshake traffic keys, which only the two peers derive. An alert received as a protected record therefore came from the peer that completed the key exchange, so "something in the middle is injecting errors" no longer explains this alert. It can still explain events from earlier in the exchange, while everything was unprotected.
Does arrival point ever identify a single cause on its own?
No. It removes members from the candidate set - often most of them - but the remaining set still has several entries, and a peer is free to send a vague description at any point. Combine it with the description and with which side sent it; the three together are usually enough to choose one experiment rather than five.

saying these in an interview costs you the question

Accepts a certificate verdict that arrived before any Certificate message
Thinks a protected alert could have been produced on the path
Applies the TLS 1.3 protection argument to a TLS 1.2 exchange
Reads decrypt_error(51) as a verdict on a certificate's contents
Believes arrival point identifies one cause rather than removing many
Trusts an application's error wording over the message ordering

In a TLS 1.3 handshake, what does the point in the flight at which an alert arrived rule out about its cause?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~3 min

Description, direction, position

Before ServerHello

After ServerHello: a protected alert has an author

Three arrivals, three eliminations

What TLS 1.2 changes

What position never tells you

Why interviewers reach for this

▾common follow-ups3 questions

▾red flags6 flags

Description, direction, position

Before ServerHello

After ServerHello: a protected alert has an author

Three arrivals, three eliminations

What TLS 1.2 changes

What position never tells you

Why interviewers reach for this

answer

go deeper