Why do Go TLS servers behind one load balancer need tls.Config.SetSessionTicketKeys given identical keys?

## What a session ticket is A full TLS handshake costs a round trip and real asymmetric cryptography. Resumption avoids most of that: the server hands the client a **session ticket** — a blob containing the state needed to resume, encrypted and authenticated under a key the server holds. The client stores the opaque blob and presents it on a later connection; the server decrypts it and short-circuits the expensive part. This is stateless on the server's side: nothing is stored, everything the server needs comes back inside the ticket. That property is what makes the ticket key so important, because possession of the key is the *only* thing that lets a server read a ticket. ## The default in Go, and why it breaks across replicas When you do not configure anything, a Go server generates a session ticket key at random inside the process and rotates it periodically on its own. For one server this is a good default — it is one less secret to manage and the automatic rotation limits how much resumable traffic a single stolen key covers. Behind a load balancer it produces a subtle degradation. Replica A issues a ticket encrypted with A's key. The client comes back a minute later, the balancer sends it to replica B, and B cannot decrypt a thing. The client is not rejected: TLS falls back cleanly to a full handshake and the request succeeds. What you observe is a resumption rate near zero, extra round trips on connection setup, and asymmetric CPU that scales with connection churn rather than with request volume. Nothing in the logs says "resumption failed". The same thing happens to a single server across a restart, and across a rolling deploy, since a fresh process invents a fresh key. ## The API ```go func (c *tls.Config) SetSessionTicketKeys(keys [][32]byte) ``` Each key is 32 bytes. The list has an ordering rule that is the whole of the rotation story: - the **first** key is used to encrypt newly issued tickets; - **all** keys in the list may be used to decrypt a presented ticket. It is safe to call while the server is running, which is what lets you rotate without a restart, and it panics if `keys` is empty — pass at least one, and use `tls.Config.SessionTicketsDisabled` if what you actually want is no tickets at all. ## Rotating the ticket keys The ordering rule gives you exactly the overlap this leaf is about — the retiring key still verifying while the new one signs, expressed in ticket terms: 1. Generate a new 32-byte key and distribute it to every replica. 2. Once every replica has it, call `SetSessionTicketKeys` on each with the new key **first** and the retiring key still present. From this moment new tickets are encrypted under the new key and old tickets still decrypt. 3. Wait out the lifetime of tickets issued under the retiring key. 4. Call `SetSessionTicketKeys` again without it. The two ordering mistakes are the interesting ones. Promote the new key to first *before* every replica has the list and clients get tickets that some replicas cannot read. Drop the retiring key too early and every outstanding ticket is dead, giving you a burst of full handshakes — a CPU spike, not an outage, but a visible one on a busy fleet. How the key material reaches the replicas is a secret-distribution question rather than a Go one; what Go pins down is that the list must be identical and that the swap itself is a live call, not a restart. ## The tradeoff you are actually making Sharing one ticket key across a fleet trades a security property for a performance one. A session ticket key is a long-lived symmetric secret that can decrypt every ticket issued under it, and that undermines forward secrecy for resumed sessions: an attacker who records traffic and later obtains the ticket key can unwrap sessions that were resumed with it. Go's per-process auto-rotation is generous on this axis precisely because those keys are short-lived and never leave the process. When you pin a shared key, you take responsibility for rotating it on a schedule and for the blast radius if it leaks. "Set once at deploy and never think about it again" is the failure mode: the key ends up years old, in every config store, and shared with people who have long since left. ## What it is not The session ticket key is not the server's private key and has nothing to do with the certificate chain. Rotating one has no effect on the other; they have different lifetimes, different distribution stories and different consequences on compromise. Confusing the two is the most common mistake in this area — a candidate who says "we rotate the ticket keys when the certificate is renewed" has coupled two unrelated schedules for no reason. ## How you would notice Because the failure is invisible in error rates, you find it by measuring resumption: a counter of full versus resumed handshakes, or simply handshake CPU that tracks connection rate. A fleet that suddenly stops resuming after being scaled out, or after connections stopped being pinned to a replica, is the classic story.