Two other ways involve looking at the first response packet sent by the server after the Client Hello. If you don't see any packets (because they are all filtered out), then you don't have the full SSL handshake. That should display packets that contain a certificate. One is to use the display filter ' = 11'. There's a couple of ways I can think of to verify this. The packet capture was using the -s0 optionĪs hoolio correctly stated, you must capture the entire SSL handshake in order for wireshark to decrypt it. I did that on the version 11 it did not work. Maybe someone could clarify if I'm off-base? And if that's the case, is there a propery in the SSL client profile I can adjust to force the LTM to always perform a full certificate transfer? I'm not entirely sure about this, but my understanding was that an LTM can cache the SSL certificate? That might explain why I can't seem to capture the entire key transfer.

'ssl_generate_keyring_material not enough data to generate key'

I viewed a Wireshark video on SSL and looked closely at the SSL debug log in Wireshark, and both seem to point to the fact that I haven't captured the 'full' SSL key transfer: More recently, I've had no success at all. I've always had hit-and-miss success (more misses than hits) decrypting HTTPS in this manner. * SSL private key on local filesystem (from /config/ssl/ssl.key on LTM) In the 'RSA Keys List:', specify the following parameters seperated by commas: I know it is possible to decrypt an HTTPS conversation between a client and a virtual server with Wireshark - I've done it before by specifying a couple of parameters in the SSL protocol preferences (Edit -> Preferences -> Protocols -> SSL).

Wireshark decrypt ssl application data