When TLS uses RSA key exchange, the server’s private key is the piece that unlocks the session keys needed to decrypt the traffic. The client sends a pre-master secret encrypted with the server’s public key; the server uses its private key to decrypt that secret, and from there both sides derive the master secret and the symmetric keys used to encrypt and decrypt the subsequent records. That’s why providing the server’s private key in Wireshark allows it to reconstruct the session. So the right approach is to import the server’s private key corresponding to the certificate shown in the handshake, in a format Wireshark can read (typically PEM), enable TLS decryption in Wireshark’s settings, and ensure the capture uses RSA key exchange (not ephemeral methods like ECDHE). If the handshake uses an ephemeral key exchange such as ECDHE, the private key alone won’t enable decryption because the session keys aren’t derived from the server’s private key; in that case you’d need a client-side key log or another method to obtain the master secrets. This is why the server private key approach works only for RSA key exchange and not for other key exchange methods.