Certificate Messages

## The two messages, and the order they arrive in A TLS 1.3 server that authenticates with a certificate does it with **two** consecutive handshake messages, not one: 1. **`Certificate`**, handshake type `certificate(11)`, carries the chain. Its body is a `certificate_list`: a sequence of `CertificateEntry` structures, each holding one certificate plus an extension block scoped to that entry. 2. **`CertificateVerify`**, handshake type `certificate_verify(15)`, carries a signature. The server signs a value derived from the transcript of every handshake message exchanged up to that point, using the private key belonging to the certificate in the **first** entry of the list. `Finished` then closes the server's flight, and only after that may application data flow. ## Why the chain on its own proves nothing A certificate is a public document. Every client that has ever connected holds a copy, a public log may hold one, and anyone who recorded an older handshake has one. Presenting it says only "a certificate authority signed this document"; it says nothing about whether the sender holds the private key the document names. That is exactly the gap `CertificateVerify` closes: - the signature is over the **handshake transcript**, which includes the client's own freshly generated `ClientHello`, so a signature lifted from a recorded handshake will not verify in this one; - it is made with the key of the **first** certificate in `certificate_list`, which is why the ordering rule exists — the first entry is the sender's own certificate, never an intermediate; - the message names the signature scheme that was used, and that scheme has to be one the client said it would accept. Without the second message, an attacker who simply replays a captured `Certificate` message would be indistinguishable from the real server. ## What each entry in the list holds - The **first** `CertificateEntry` is the server's end-entity certificate — the one whose key signs `CertificateVerify`. - Following entries are the intermediate certificates that link it upward, each normally certifying the entry immediately before it. - A certificate that names a trust anchor the peers are expected to hold already may be omitted from the list entirely. - Every entry carries its own extension block; that block is where TLS 1.3 places a stapled status response, per certificate rather than per handshake. ## TLS 1.2 kept the server's proof somewhere else | | TLS 1.2 | TLS 1.3 | |---|---|---| | Server sends `Certificate` | yes | yes | | Server sends `CertificateVerify` | no | yes | | Where the server proves key possession | in `server_key_exchange (12)` for ephemeral suites; implicitly, by decrypting the client's key material, for static RSA key transport | in `CertificateVerify` | | Who else sends `CertificateVerify` | the client only, answering a `CertificateRequest` | the client, answering a `CertificateRequest` | So "the server sends `CertificateVerify`" is a **TLS 1.3** statement. The guarantee existed in TLS 1.2 too, but it lived in a different message, and the name `CertificateVerify` referred to the client's message alone. Dropping the version is the most common inaccuracy on this material. ## Reading the pair when a handshake goes wrong Splitting the two jobs splits the failures, which is what makes the distinction practical rather than trivia: - a problem with **what was sent** — a missing intermediate, entries in the wrong order, a certificate naming no host the client asked for — is a `Certificate` problem, and is visible to anything that can print the chain the server actually put on the wire; - a problem with **the proof** — a signature that does not verify, or a scheme the client never offered — is a `CertificateVerify` problem, and re-issuing certificates will not touch it; - a server holding no certificate compatible with what the client offered fails before either message is built. ## What the pair is not - It is **not path validation**. The server puts a list on the wire; the client builds and checks a path from it up to an anchor it already trusts. Those are different operations with different failure modes. - It is **not a statement about revocation**. Neither message asserts the certificate is still valid today; a status response, when one is present at all, rides as an extension. - It is **not client authentication**. The client has its own `Certificate` and `CertificateVerify` pair, but sends it only in answer to a `CertificateRequest`. - It **does not carry the private key**. Nothing in either message reveals it. The signature is the only evidence of that key that ever crosses the wire.