Continuing the discussion from Weird ‘hex’ (?) IP addresses in Apache access logs:
It's possible for Wireshark to decrypt TLS traffic by configuring it with a copy of the server's private key, but as @Osiris pointed out, that requires that the server and client negotiate a non-forward secret cipher suite. In TLS 1.3 that's impossible because all cipher suites are forward secret, and even on TLS 1.2 and below, if the server is well-configured and the browser is modern, it should also be impossible.
In non-forward secret handshakes, the server sends the "server random" in the clear; the client sends the "pre-master secret" encrypted to the server's RSA key, and both sides calculate the master secret based on that. So you can see that possession of the RSA private key is sufficient to decrypt the pre-master secret and thus deduce the master secret and decrypt the whole session.
However, in forward secret sessions, both sides use Diffie-Hellman to negotiate a master secret, which means the necessary info to calculate the master secret never actually crosses the wire! It's a remarkable property and still hard to wrap my head around. It means even if you have the server's private key, you can't decrypt the session, which is the whole point of forward secrecy.
However, obviously at least two parties are able to decrypt the session: the client and the server. That's where the SSLKEYLOGFILE option that @_az pointed out comes in. Some software (at least Firefox, I think also Chrome), will let you turn on an option to just log all of the master secrets it calculates during handshakes. Wireshark can then use those master secrets to decrypt sessions. Obviously, keeping this log of secrets on disk is a bit of a risk to the forward secrecy of your connections, and it's meant only as a debugging technique.
One last note: The choice of RSA key exchange is somewhat independent of the type of key the server certificate uses. A server using a certificate for an RSA public key can do RSA key exchange (bad, not forward secret), DHE key exchange (slow, unpopular), or ECDHE key exchange (cool, popular). However, a server using a certificate for an ECDSA public key can only do DHE or ECDHE key exchange, not RSA.