In TLS 1.3, what must a client advertise before a server may request a certificate after the handshake has finished?

## The opt-in comes first Post-handshake authentication is the mechanism for asking a peer to authenticate after the connection is already carrying application data. The asking is not unilateral. The client must have included `post_handshake_auth(49)` in its `ClientHello`, which is a statement of willingness made before anything else happened. A server that receives no such extension must not send a late `CertificateRequest`, and a client that never sent it and receives one anyway treats it as a protocol violation and aborts the connection with a fatal alert. This ordering is deliberate. It means a client always knows, from the moment it opens the connection, whether it can be interrupted later, and no implementation has to handle a surprise request it was never built for. ## The exchange 1. The client sends `post_handshake_auth(49)` in its `ClientHello`, at connection setup. 2. The handshake completes normally, and application data flows. 3. At some later point the server sends `CertificateRequest` with a **non-empty** `certificate_request_context`. 4. The client replies with `Certificate` carrying that same context, then `CertificateVerify`, then `Finished`. The context is what makes the exchange workable. Several requests can be outstanding at once, and each answer names the request it belongs to, so the server never has to guess which challenge a reply satisfies. In the main handshake the context is empty, because there is only one request and no ambiguity to resolve. Everything else follows the rules of the ordinary case: the client that has nothing acceptable sends an empty `certificate_list`, and the `CertificateVerify` signature covers the transcript, so the proof is bound to this connection and not reusable elsewhere. ## Why it is not renegotiation TLS 1.2 achieved the same effect by renegotiating: running a second handshake inside the established connection, this time asking for a certificate. **TLS 1.3 removed renegotiation entirely.** There is no second handshake to run, and the key-refresh job that renegotiation also served is handled by `KeyUpdate` instead. So post-handshake authentication is not renegotiation under a new name. The differences are structural: - it is a few messages inside the existing connection, not a fresh handshake; - it requires prior consent from the client, which renegotiation did not; - it changes nothing about the negotiated parameters, only the peer's authenticated state; - it can be requested repeatedly, each request distinguished by its own context. ## Where it fits poorly The mechanism has a real limitation worth naming, because it is the reason many deployments never use it. Post-handshake authentication operates on the **connection**. On a protocol that multiplexes many concurrent exchanges over one connection, nothing ties the challenge to whichever exchange provoked it, and nothing stops other exchanges continuing while the answer is in flight. A service that wanted to say *this particular operation needs a stronger identity* cannot express that; it can only say *this connection should now be authenticated*. On a crane control link the fit is better, because the connection is long-lived, dedicated and carries one stream of control traffic. A plausible use is a link that comes up for telemetry with no client certificate and is challenged only when a command that moves equipment arrives, so the strong identity is demanded at the moment it matters rather than kept open all day. ## What to check when it does not work | symptom | most likely cause | |---|---| | the client aborts as soon as the late request arrives | the client never sent `post_handshake_auth(49)` | | the server never sends a late request at all | the extension was not offered, so the server is barred from asking | | an answer arrives and the server cannot pair it | the request context was empty or was not echoed | | the answer carries an empty `certificate_list` | the client has nothing matching the request's constraints | The compact summary: the client consents at `ClientHello` time, the server challenges later with a context, the answer echoes the context, and none of it is renegotiation, because renegotiation no longer exists.