This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Server Certificate packet format

0

I can't find a writeup on the format of the Server Certificate - i.e. what all the bytes are and the different variations. I have a couple of TLS/SSL books and papers, but they don't have anything on the actual format of the packet. Can someone point me in that direction? I'm trying to figure out where the public key is embedded and what all the other bytes mean.

Thanks.

Sutton

asked 05 Jul '17, 08:34

dodge55's gravatar image

dodge55
21●4●4●9
accept rate: 0%

2 Answers:

1

The Certificate message is defined in RFC 5246, Section. 7.4.2:

  opaque ASN.1Cert<1..2^24-1>;
  struct {
      ASN.1Cert certificate_list<0..2^24-1>;
  } Certificate;

In TLS, this notation for certificate_list means that there is a vector with a length prefix (three bytes since the maximum value is 224-1) followed by zero or more ASN.1Cert types. These are also vectors with a three byte length prefix followed by an ASN.1-encoded X.509 certificate.

In Wireshark, you can select the Certificate field, expand it subfields and study the bytes view at the bottom of the screen. See for example this screenshot where the Certificate is selected with a sample file (linked at the bottom of this post):

Screenshot of Wireshark with Certificate message selected

Alternatively, you can export the selected ASN.1 bytes for inspection with alternative tools. Right-click on the selected Certificate field and use the Export Packet Bytes (Ctrl-H) option. Save the file as file.der (for example). Then you can study its contents using the openssl tool:

$ openssl x509 -inform DER -in cert.der -noout -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            f5:11:56:e9:b6:1e:35:c9
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN = localhost
        Validity
            Not Before: Feb  7 11:30:11 2015 GMT
            Not After : Mar  9 11:30:11 2015 GMT
        Subject: CN = localhost
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (1024 bit)
                Modulus:
                    00:9b:a9:75:12:18:1c:46:06:dc:8d:11:b8:f7:f4:
                    ...
                    d2:56:fe:22:59:c8:51:68:a1
                Exponent: 65537 (0x10001)
        ...

An alternative tool that displays the mechanical interpretation, completely with offsets, lengths and the contents:

$ openssl asn1parse -in cert.der -inform DER -i -dump
    0:d=0  hl=4 l= 502 cons: SEQUENCE          
    4:d=1  hl=4 l= 351 cons:  SEQUENCE          
    8:d=2  hl=2 l=   3 cons:   cont [ 0 ]        
   10:d=3  hl=2 l=   1 prim:    INTEGER           :02
   13:d=2  hl=2 l=   9 prim:   INTEGER           :F51156E9B61E35C9
   24:d=2  hl=2 l=  13 cons:   SEQUENCE          
   26:d=3  hl=2 l=   9 prim:    OBJECT            :sha256WithRSAEncryption
   37:d=3  hl=2 l=   0 prim:    NULL              
   ...
  115:d=2  hl=3 l= 159 cons:   SEQUENCE          
  118:d=3  hl=2 l=  13 cons:    SEQUENCE          
  120:d=4  hl=2 l=   9 prim:     OBJECT            :rsaEncryption
  131:d=4  hl=2 l=   0 prim:     NULL              
  133:d=3  hl=3 l= 141 prim:    BIT STRING        
      0000 - 00 30 81 89 02 81 81 00-9b a9 75 12 18 1c 46 06   .0........u...F.
      0010 - dc 8d 11 b8 f7 f4 21 99-0b 1b 96 6b 42 f1 4b 48   ......!....kB.KH
      ...
      0080 - 56 fe 22 59 c8 51 68 a1-02 03 01 00 01            V."Y.Qh......
    ...

Documentation for these two tools can be found here:

The capture I used above is taken from the SampleCaptures wiki, http2-16-ssl.pcapng.

answered 05 Jul '17, 09:21

Lekensteyn's gravatar image

Lekensteyn
2.2k●3●7●24
accept rate: 30%

Many thanks for that. In looking at the RFC and my Wireshark output, there are several byte sequences in the Certificate that are not referenced in either the RFC or the Wireshark output. For example, between the version and the serial number, there are 2 undocumented bytes. And, the first 12 bytes of the certificate before the version number don't seem to be documented. At least WS skips over those. Any idea what those are?

Sutton

(05 Jul '17, 11:45) dodge55

ASN.1 BER (Basic Encoding Rules) use TLV (type-length-value) encoding of fields, so in particular the two bytes you mention, "between" the version and the serial number, say the following:

02 - integer

09 - consisting of 9 octets

The information that the meaning of this 9-byte integer is a serial number is implicit, as the serial number is the second item of the certificate as defined in X.509:

Certificate ::= SIGNED SEQUENCE{
    version [0]Version DEFAULT 1988,
    serialNumber SerialNumber,
    signature Algorithmidentifier
    issuer Name
    validity Validity,
    subject Name,
    subjectPublicKeyInfo SubjectPublicKeyInfo}

Version ::= INTEGER { 1988(0)}
SerialNumber ::= INTEGER
Validity ::=
SEQUENCE{
notBefore UTCTime,
notAfter UTCTime}


…

Both the sender and the recipient know what to expect at what place as they both “know” the ASN.1 description.

Similarly, the 02:01 “before” the version say that the version is a single-octet integer, and the 30:82:01:5f:a0:03 together say that what follows is a structure called signedCertificate.

Most Wireshark dissectors prefer readability to detailed explanation of the structure, so this information is not added to the dissection tree.

(05 Jul ‘17, 12:06) sindy

Thanks. In many of the other packet descriptions (RFC and books), TLV bytes are explicitly mentioned. So, I thought it may be that, but I wasn’t totally sure. Being somewhat new to SSL, I like to be sure. Thanks for responding.

(05 Jul ‘17, 12:58) dodge55

Actually, ASN.1 BER are more complex than just TLV, as more than a single byte may be used to encode the type and more than a single byte may be used to encode the length, or the length may not be specified at all. Second, ASN.1 has its own standard including the BER, X.690, where all this is detailed; X.509 refers to X.690 many times, often adding constraints where X.690 is not strict enough. With ITU recommendations, you rarely find everything you need in a single one, and the reference chains may be really long.

(05 Jul ‘17, 13:09) sindy

Disclaimer have not looked at the actual trace. The wiredhark ber decoder has a preference to show internal ber decoding if you are really interested in the gory details.

(05 Jul ‘17, 14:40) Anders ♦

I see the TLV occurrences in the packet. However, still not sure how the 30:82:01:5f:a0:03 is decoded to a structure ‘signedCertificate’. Maybe you can elaborate. My packet has 2 such 30:82:… sections.

“Similarly, the 02:01 “before” the version say that the version is a single-octet integer, and the 30:82:01:5f:a0:03 together say that what follows is a structure called signedCertificate."

(07 Jul ‘17, 07:46) dodge55

Follow the suggestion of @Anders: go Edit->Preferences->Protocols->BER and click the topmost option - Show internal BER encapsulation tokens.

That way, Wireshark will show you the meaning of the individual bytes.

(07 Jul ‘17, 07:50) sindy
showing 5 of 7 show 2 more comments

0

The certificate used is an X.509 certificate, see RFC 5280 (updated by RFC 6818).

answered 05 Jul '17, 09:03

grahamb's gravatar image

grahamb ♦
19.8k●3●30●206
accept rate: 22%

Thanks. Big help. Not sure why I never found that and my books and papers don't reference that RFC in the certificate section.

(05 Jul '17, 09:13) dodge55

If an answer has solved your issue, please accept the answer for the benefit of other users by clicking the checkmark icon next to the answer. Please read the FAQ for more information.

(05 Jul '17, 09:14) cmaynard ♦♦