The answer to your question is
No, because of ECDHE_RSA.
Now let us see why this is so. Let's look at the entire ciphersuite specification TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 in detail:
- TLS - the protocol
- ECDHE_RSA - authentication and key exchange algorithms
- WITH_AES_128 - the encryption/decryption algorithm
- GCM - the mode used for scrambling the data so it can be securely used with the algorithm
- SHA256 - message authentication code algorithm
The key exchange algorithm is specifying how keys for the bulk encryption/decryption cipher are exchanged. And there is something special about the Diffie-Hellman key exchange used in ECDHE_RSA:
DHE_RSA offers something known as Perfect Forward Secrecy, a pompous name for the following property: if your server gets thoroughly hacked, to the point that the attacker obtains a copy of the server private key, then he will also be able to decrypt past TLS sessions (which he recorded) if these sessions used RSA, while he will not be able to do so if these sessions used DHE_RSA.
stolen from an answer on security.SE
In other words, with (EC)DHE, the AES key used for encryption and decryption cannot be retrieved from the TLS ciphertext conversation, not even if you have the server's private key.
This is different when solely relying on RSA for key exchange: in this operation mode, the bulk cipher key to be used is generated by the client, RSA-encrypted with the server's public key and sent to the server. If an eavesdropping third party has the server's private key, it simply can decrypt the RSA ciphertext of the key exchange, get at the bulk cipher key and decrypt eveything else. This is exactly what Wireshark is doing when decoding a TLS stream for you.
So, what works for RSA-based key exchanges, won't do for DHE-based ones.
Wireshark since 1.6 (about 5 years ago) in addition to akRSA-using-serverkey can also decrypt SSL/TLS using per-session premaster or master secret extracted from either endpoint. Firefox/NSS and Chrome can do this using SSLKEYLOGFILE; other programs vary, and Q didn't mention any programs. See security.stackexchange.com/questions/35639/… (but +1 for a wabbit supporting a bear :)
@dave_thompson_085 I took the question as one from a server admin looking at existing packet captures trying out to figure what went wrong. But thank you for bringing in this additional aspect. Even without control over the clients and not pushing the server-side ability to export master keys, for new captures he might modify his web server infrastructure and decrypt all communications as a man-in-the-middle.