Why won't a server's private key decrypt a TLS 1.3 session your sensor already captured?

## The question behind the question A competent engineer who ran passive inspection ten years ago will answer this with *put the server key on the sensor*, because that architecture worked and was standard. The correcting fact is that it stopped working, and understanding why is what stops you designing around a capability you no longer have. ## What the long-term key does now In TLS 1.3 the certificate's private key is used for one thing during a full handshake: producing a signature over the handshake transcript, which proves to the client that the party holding the certificate is on the other end. It never encrypts, transports or wraps the traffic secret. Possession of it lets you *impersonate* the server going forward; it does not let you read anything that already happened. ## Where the session keys actually come from Both sides send a key share - a public value in an ephemeral Diffie-Hellman group, commonly the elliptic curve X25519. Each holds the matching private value in memory for the life of the connection, and they combine their halves into a shared secret from which the handshake and application traffic keys are derived. When the connection ends, those private values are gone. There is no copy anywhere. That property has a name - forward secrecy - and its point is exactly that a later compromise of the long-term key, by theft, subpoena or escrow, does not retroactively open recorded sessions. A passive sensor watching that exchange sees both public shares and can do nothing with them, because deriving the shared secret from two public values is the hard problem the whole construction rests on. ## What changed, and when TLS 1.2 offered static RSA key-transport suites: the client generated the pre-master secret and encrypted it to the server's public key. Anyone holding the private key could decrypt that message from a capture and derive everything else. An entire generation of passive inspection appliances was built on that, and the deployment pattern - hand the sensor a copy of the certificate keys - is still muscle memory for a lot of architects. ECDHE suites in TLS 1.2 already broke it wherever they were negotiated; TLS 1.3 finished the job by removing static key transport from the protocol entirely. There is no cipher-suite policy you can apply to your own servers that brings it back, and none you can apply to a server you do not own. ## The stronger point for a mirrored implant session Even if key escrow still worked, look at the direction of the traffic that matters. The session under investigation is *outbound*: a workload inside your cloud virtual network to a host the adversary controls. The server side of that handshake is theirs. You have no certificate, no key, no key-management system entry - nothing to escrow, hypothetically or otherwise. Key escrow was only ever a story about inbound traffic to servers you own. For egress it was never on the table. ## What would actually get you plaintext, and what it costs There are exactly two honest routes, and neither is a setting on the sensor. - **Leave the passive position.** Put a terminating position in the egress path so that you are one endpoint of the client's session and the other endpoint of a fresh session onward. Now you are in the traffic path with an availability cost, you hold plaintext, and clients that pin a certificate or public key will fail the connection rather than accept a substituted chain. That is a different architecture with a different owner and a different bill. - **Instrument the software.** A process you control can export its session secrets, which lets a sensor decrypt exactly those sessions. It scales per workload, it covers only software you own, and the adversary's implant will never cooperate - which is the whole point. Your visibility grows over your own estate and stays zero over theirs. ## The honest consequence The useful sentence to be able to say in an interview and in a design review is that this is a *protocol property*, not a gap in your tooling, your budget or your retention. Sensors, storage and vendor licences do not move it. Once you accept that, the questions become the right ones: what can the residue support, where does plaintext genuinely exist, and is buying a terminating position worth what it costs?