You can pull the SSL certificate right out of a Wireshark capture file, even if you didn’t grab it live.
Let’s say you’ve got a capture (capture.pcap) of a client connecting to a web server over HTTPS. You want that server’s certificate.
First, open your capture file in Wireshark. You need to filter for the TLS handshake, specifically the Client Hello and Server Hello packets. A good filter is tls.handshake.type == 1 or tls.handshake.type == 2.
Once you’ve got those packets, you can tell Wireshark to follow the stream. Right-click on one of the Server Hello packets (or any packet within the TLS handshake) and select "Follow" -> "TLS Stream". This will open a new window showing the raw TLS data for that connection.
Now, in the "Follow TLS Stream" window, look for the "Export Certificate" button. Click it. Wireshark will then prompt you to save the certificate to a file. Choose a name and location, and it’ll save it as a .cer or .pem file.
That’s it. You’ve got the certificate.
But what if you want to automate this, or you have a lot of certificates to extract? You can use tshark, the command-line version of Wireshark.
Here’s how you’d do it with tshark:
tshark -r capture.pcap -Y "tls.handshake.type == 11" -T fields -e tls.handshake.certificate
This command does a few things:
-r capture.pcap: Reads the specified capture file.-Y "tls.handshake.type == 11": This is the display filter.tls.handshake.type == 11specifically targets theCertificatehandshake message from the server. This is more direct than looking for theServer Hello.-T fields: Tellstsharkto output fields.-e tls.handshake.certificate: Specifies the field to extract, which is the raw certificate data itself.
The output of this command will be the raw certificate data, often in PEM format, printed directly to your terminal. You can then redirect this output to a file:
tshark -r capture.pcap -Y "tls.handshake.type == 11" -T fields -e tls.handshake.certificate > server.pem
This creates a file named server.pem containing the extracted certificate.
You might notice that sometimes the certificate isn’t directly in the Certificate handshake message itself, but rather in a subsequent New Session Ticket or other TLS extension data. In those cases, the direct extraction using -e tls.handshake.certificate might not work as expected. The "Follow TLS Stream" GUI method is more robust for these edge cases because it reconstructs the entire TLS session.
If you’re dealing with a capture that has multiple TLS connections, you’ll need to run the tshark command for each connection, or use more advanced scripting to parse the output and identify individual certificates. One way to do this is to filter for the Client Hello and Server Hello pairs and then process each pair individually, or to look for specific IP addresses or hostnames if you know them.
The beauty of extracting the certificate this way is that you can analyze it offline, check its validity, expiry, issuer, and subject without needing to re-establish the connection or have access to the original server. It’s a powerful forensic and debugging tool.
If you’re extracting certificates from a capture where the client is sending its certificate (e.g., mutual TLS authentication), you’d change the filter. For a client certificate, you’d look for tls.handshake.type == 11 but filter by client IP or specific TLS extensions that indicate client authentication. The field to extract would likely remain the same, but the context of which side is sending it changes.
One subtle point is that the certificate you extract is the one the server presented at that specific time. If the server uses different certificates for different clients, or if it rotates its certificates, the extracted certificate is a snapshot. It’s not necessarily the server’s "permanent" certificate.
After you’ve successfully extracted a certificate, the next challenge you’ll likely face is verifying its authenticity against a trusted Certificate Authority (CA) or debugging why a TLS handshake failed in the first place.