Ask Your Question

How to extract certificate from SSL session setup trace

asked 2019-10-09 10:19:19 +0000

MWRMWR gravatar image

Hi, I have been working with Wireshark for years particularly as I use the Riverbed trace analysis programs daily. I found ways on the Internet to extract certificates from an SSL session trace. All the info I found seems to speak about fields I don't find in my version of WS (I tried 2.4.0 and 2.6.3. Expanding the SSL details on my trace shows:

Frame 3871: 1402 bytes on wire (11216 bits), 256 bytes captured (2048 bits)
Ethernet II, Src: Cisco_f3:00:11 (d4:2c:44:f3:00:11), Dst: HewlettP_6f:21:d0 (f4:39:09:6f:21:d0)
Internet Protocol Version 4, Src:, Dst:
Transmission Control Protocol, Src Port: 8080, Dst Port: 57248, Seq: 40, Ack: 752, Len: 1348
Hypertext Transfer Protocol 
Secure Sockets Layer
 TLSv1.3 Record Layer: Handshake Protocol: Server Hello
    Content Type: Handshake (22)
    Version: TLS 1.2 (0x0303)
    Length: 122
    Handshake Protocol: Server Hello
        Handshake Type: Server Hello (2)
        Length: 118
        Version: TLS 1.2 (0x0303)
        Random: 679cb032893ff093df50b2aad0ef633b8e1923abb79837f8...
        Session ID Length: 32
        Session ID: f8046d1805478fa3cc6658da57be9a03ba6807a79094af06...
        Cipher Suite: TLS_AES_128_GCM_SHA256 (0x1301)
        Compression Method: null (0)
        Extensions Length: 46
        Extension: key_share (len=36)
        Extension: supported_versions (len=2)
 TLSv1.3 Record Layer: Change Cipher Spec Protocol: Change Cipher Spec
    Content Type: Change Cipher Spec (20)
    Version: TLS 1.2 (0x0303)
    Length: 1
    Change Cipher Spec Message

I understand I should find the certificate line and click right to export, but there is no certificate line. What am I doing wrong or not seeing?



edit retag flag offensive close merge delete

2 Answers

Sort by ยป oldest newest most voted

answered 2019-10-09 11:27:05 +0000

grahamb gravatar image

You're looking at the wrong TLS record.

You need to look at the TLS handshake record that sends the server certificate. Use the display filter tls.handshake.type == 11 to find certificate records.

Note that 3.0.5 is the current stable release version of Wireshark.

edit flag offensive delete link more


Hello grahamb

I agree that I had to update my version of WS to have a filter capability, but even then tls.handshake.type appears to have a value of 0 through 8 for me. Can"t upload pic, but value choice is:

Client Hello
Client Master Key
Client finished
Server Hello
Server Verify
Server finished
Request Certificate
Client Certificate

Sorry and thanks again. Marc

MWRMWR gravatar imageMWRMWR ( 2019-10-09 13:30:02 +0000 )edit

Hi again, After checking again, could I have a different formatting/interpretation because I am tracing the client TO PROXY connection (on port 8080) not the Proxy to actual server (on port 443) connection?

MWRMWR gravatar imageMWRMWR ( 2019-10-09 13:38:12 +0000 )edit

Do you have the TCP preference "Allow subdissectors to reassemble TCP streams" enabled? This is required as a TLS certiificate often extends over multiple TCP segments so must be reassembled.

grahamb gravatar imagegrahamb ( 2019-10-09 16:07:41 +0000 )edit

Hi Yes this option was required in the post I followed in the first place. It was, as still is checked. Could you please let me know what I would see in the INFO filed of the correct record to work on, or would some handshake message sequence be available somewhere to show it ? Thanks for your time and help


MWRMWR gravatar imageMWRMWR ( 2019-10-10 07:01:31 +0000 )edit

But I see that the packet I am analysing is maxed out in size and followed by another also maxed and a third half empty, so I think you are right: somehow the PC-to-Proxy message may not be re-assembled (maybe things work slightly different due to using the proxy). I will try tracing on the other side of the proxy to have a proxy-server trace. I'll let you know

MWRMWR gravatar imageMWRMWR ( 2019-10-10 07:06:17 +0000 )edit

answered 2019-10-09 18:44:39 +0000

SYN-bit gravatar image

In your example, the ChangeCipherSpec comes straight after the ServerHello. This means this is a resumed session (either cached on both client and server or there was a TLS ticket). In resumed sessions the authentication of the server certificate (and in case of mutual TLS, also the client certificate) has already taken place so the cetificate(s) will not be exchanged.

If this is a test with a browser, make sure you start your capture before you open your browser (and close all open browser windows before you start).

edit flag offensive delete link more


The wireshark trace I was using was not recording the entire length of each packet, so Wireshark was not interpreting the packet correctly and displaying 'Packet size limited during capture') I had not identified the error because the 'Server Hello' packet does not mention 'limited' The correct packet containing the certificates is, apparently the second one just after the one marked 'Server Hello' and, when interpreted correctly by WS, is marked 'Certificate' and has a Tls.handshake.type of 11, as grahamb pointed out. Thanks for your help


MWRMWR gravatar imageMWRMWR ( 2019-10-10 08:45:09 +0000 )edit

@SYN-bit, I think your answer was intended for another TLS question, maybe this one?

grahamb gravatar imagegrahamb ( 2019-10-10 09:44:46 +0000 )edit

@grahamb No, it was indeed a response to this question. However, I did not look close enough. In a TLSv1.2 handshake my answer made sense, I did not notice that this is a TLSv1.3 handshake where things are different :-)

SYN-bit gravatar imageSYN-bit ( 2019-10-10 16:24:10 +0000 )edit

@SYN-bit, ACK, I was looking at this question.

grahamb gravatar imagegrahamb ( 2019-10-10 17:15:44 +0000 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2019-10-09 10:19:19 +0000

Seen: 34,365 times

Last updated: Oct 10 '19