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

How do I extract the x509 commonName from a capture of the SSL handshake?

0

How do I extract the x509 commonName from a capture of the SSL handshake?

I want all of the subject fields and all of the issuer fields from the signedCertificate(s). This works but only gets the last printableString from the signing authority.

tshark -r ssl.pcap -E header=y -T fields -e x509sat.printableString

I want the first certificate and all fields from the subject and issuer. I started using the GUI and looking at the bottom pane to get the names of everything and using tshark -G but no luck so far.

I am using tshark -v 1.0.3, maybe there have been improvements in this area since this version?

Any help is appreciated. Thanks.

asked 23 Mar '12, 14:18

rafs's gravatar image

rafs
6225
accept rate: 50%

I discovered the "-V" option and I can work with this, but if there is a way to traverse this tree and selectively print the elements that would be even better.

(23 Mar '12, 23:54) rafs

tshark -r ssl.pcap -R ssl.handshake.certificate -V

(23 Mar '12, 23:55) rafs

I am just wondering if I need to write my own parser or will the tshark parser allow me to get the information I want all as tab delimited fields, one-line per handshake, using the -Tfields option.

(24 Mar '12, 18:31) rafs

The first one works but not the second:

$ tshark -r $PCAP -R "ssl.handshake.certificate" -Tfields -e x509sat.CountryName

JP

$ tshark -r $PCAP -R "ssl.handshake.certificate" -Tfields -e x509sat.CommonName

(24 Mar '12, 19:04) rafs

Does the certificate in question have a commonName? If not, presumably -e x509sat.CommonName won't work.

(25 Mar '12, 07:20) Guy Harris ♦♦

yes, it has a id-at-commonName field

(31 Mar '12, 16:01) rafs
showing 5 of 6 show 1 more comments

3 Answers:

0

Ok, the aggregator field print option does the trick:

$ tshark -r $PCAP -R "ssl.handshake.certificate" -Tfields -E header=y -E separator=/t -E occurrence=a -E aggregator=\| -e x509sat.CountryName -e x509sat.IA5String -e x509sat.printableString -e x509sat.teletexString -e x509sat.uTF8String -e x509sat.universalString > out

x509sat.CountryName^Ix509sat.IA5String^Ix509sat.printableString^Ix509sat.teletexString^Ix509sat.uTF8String^Ix509sat.universalString$ ZA|US|US|ZA^I^IThawte Consulting (Pty) Ltd.|Thawte SGC CA|California|VeriSign, Inc.|Class 3 Public Primary Certification Authority|Thawte Consulting (Pty) Ltd.|Thawte SGC CA|PrivateLabel3-15^IMountain View|Google Inc|mail.google.com^I^I$

answered 20 Apr ‘12, 12:41

rafs's gravatar image

rafs
6225
accept rate: 50%

0

You may have a problem, depending on the character encoding which was used for the various elements of the DN.
By current X509 standards, they should all be either PrintableString or UTF8String (all recipients are required to be able to process those) or BMPString. But some Certificate Authorities (including Verisign) will still use T61String (TeletexString) or IA5String for any DN elements such as CN that contain characters outside the PrintableString character set. Some methods of standard Java certificate handling utilities will not process T61String in the most convenient way, if at all.

From RFC 2459:

The DirectoryString type is defined as a choice of PrintableString, TeletexString, BMPString, UTF8String, and UniversalString. The UTF8String encoding is the preferred encoding, and all certificates issued after December 31, 2003 MUST use the UTF8String encoding of DirectoryString (except as noted below). Until that date, conforming CAs MUST choose from the following options when creating a distinguished name, including their own:

  (a) if the character set is sufficient, the string MAY be
  represented as a PrintableString;

(b) failing (a), if the BMPString character set is sufficient the string MAY be represented as a BMPString; and

(c) failing (a) and (b), the string MUST be represented as a UTF8String. If (a) or (b) is satisfied, the CA MAY still choose to represent the string as a UTF8String.

answered 02 Apr ‘12, 15:19

inetdog's gravatar image

inetdog
16717
accept rate: 14%

Thanks, inetdog. I also found this document (http://www.itu.int/ITU-T/studygroups/com17/languages/X.680-0207.pdf) that apparently describes the character set encodings in way more detail than I can follow, but I think I got it.

(20 Apr ‘12, 13:52) rafs

0

I found what may be the best available solution for this problem.

$ tshark -r $PCAP -R "ssl.handshake.certificate" -Tfields -E header=y -E separator=/t -E occurrence=a -E aggregator=, -E quote=d -e x509sat.CountryName -e x509sat.IA5String -e x509sat.printableString -e x509sat.teletexString -e x509sat.uTF8String -e x509sat.universalString

$ vi out (with ":set invlist" to display invisible chars) x509sat.CountryName^Ix509sat.IA5String^Ix509sat.printableString^Ix509sat.teletexString^Ix509sat.uTF8String^Ix509sat.universalString$ "ZA,US,US,ZA"^I^I"Thawte Consulting (Pty) Ltd.,Thawte SGC CA,California,VeriSign, Inc.,Class 3 Public Primary Certification Authority,Thawte Consulting (Pty) Ltd.,Thawte SGC CA,PrivateLabel3-15"^I"Mountain View,Google Inc,mail.google.com"^I^I$

In my opinion, the “-E quote=d|s|n” is implemented wrong. It should quote the individual fields, e.g. “Mountain View”,“Google Inc”,“mail.google.com”. The current 1.6.7 version has no way for you to distinguish the x509sat strings that have commas and single quotes in the field values, e.g. sometimes the field value could be something like “Google, Inc.”.

Minor complaint aside, I say thank you to the developers that have contributed their time and talent to wireshark and tshark. This is a great tool. Thank you.

answered 20 Apr ‘12, 12:23

rafs's gravatar image

rafs
6225
accept rate: 50%