If you need to see exactly what Certificates are being exchanged between things over the network, Wireshark has the answers.

Assuming you’ve got a PCAP full of stuff, the first thing you need to do is to find the right ‘Hello’ packet. A hello packet is sent by the Client to the Server to initiate the connection between the two. Once we’ve identified this initial packet, we can then follow the conversation and get the Certificate(s) involved.

Finding the Hello Packet

Depending on what you already know, there are all sorts of ways you could use Wireshark’s Filters to identify the inital packet… You can mix and match conditions as required to help you find what you’re looking for.


Find all Client TLS Hello packets

ssl.handshake.type == 1

Find all TLS Client Hello packets from a particular IP address

ssl.handshake.type == 1 && ip.addr ==

Find all TLS Client Hello packets from a particular IP address and TCP port

ssl.handshake.type == 1 && ip.addr == && tcp.port == 443

Find all TLS Client Hello packets that contain a particular SNI

ssl.handshake.type == 1 && tls.handshake.extensions_server_name contains "mozilla.com"

Find all TLS Client Hello packets with support for TLS v1.3

ssl.handshake.type == 1 && tls.handshake.extensions.supported_version == 0x0304

Find all TLS Client Hello packets with support for TLS v1.2

ssl.handshake.type == 1 && tls.handshake.extensions.supported_version == 0x0303

Find all TLS Client Hello packets with support for TLS v1.1

ssl.handshake.type == 1 && tls.handshake.extensions.supported_version == 0x0302

Find all TLS Client Hello packets with support for TLS v1.0

ssl.handshake.type == 1 && tls.handshake.extensions.supported_version == 0x0301

Once you’ve found the Client hello, you can then follow the conversation in Wireshark until you find the corresponding Server Hello.

You could also just search straight for the Server Hello (which is sent as a response to the Client hello), by changing the Wireshark filter’s ssl handshake type, to 2.

Find all Server TLS Hello packets

ssl.handshake.type == 2

Following the conversation

Once you’ve identified the Server Hello packet, it’s time to dig a little deeper.

First, ensure that your Wireshark is set to reassemble out-of-order TCP packets. Without this, it can sometimes be very difficult to complete this next step. You can verify that Wireshark is configured to do this by going to this page in the Wireshark GUI and ensuring that any reassembly related options are ticked.

Enabling out-of-order TCP reassambly in Wireshark

Wireshark GUI:

  1. Edit > Preferences
     (A popup window should appear)

  2. In the popup window, go to "Protocols" and then "TCP"

  3. Ensure TCP reasembly options are enabled

Find the Certificate

In the packet you’ve selected, identify the Transport Layer Security section and expand the contents. You are looking for a section similar to this:

Note that, depending on the particular Server / CA / Protocol you’re dealing with, the packet capture may contain multiple Certificates. You may also notice that some of the Certificates are bigger than the others. This is because the server has basically sent everything twice. In this example, the Server’s Certificate chain includes the host its self, an issuing CA, and a Root CA. The smallest Certificate in the capture (Certificate length 1380) contains only the Root CA Public Key. The second smallest Certificate in the capture (Certificate length 1754) contains both the Root CA and issuing CA. The largest certificate in the capture (Certifiate length 2119) contains all three Certificates chained together. If in doubt, extract them all separately and inspect them individually for yourself, but it’s usually a safe bet to just extract the largest Certificate.

Extract the Certificate

Now you’ve found the Certificate, you can extract it by right clicking on the Certificate and selecting ‘Export packet bytes…’ and ave the file as a *.cer file.

Once you’ve got the file save, you can then open it in Windows like any normal Certificate.