Getting ASN.1 Issuer strings from PEM files?

Question

I recently came across an issue with Windows 2003 (apparently it also exists in other versions too), where if an SSL/TLS server is requesting client certificate authentication and it has more than 16KB of trusted certificate DNs, Internet Explorer (or any other app that uses schannel.dll) is unable to complete the SSL handshake. (In a nutshell, the server breaks the message into chunks of 2^14 bytes, as per RFC 2246 sec. 6.2.1, but Schannel wasn't written to support that. I've gotten confirmation from Microsoft support that this is a flaw in Schannel and that they're considering fixing it in a future release.)

So I'm trying to find a way to easily parse through my trusted certificates (I use Apache as my server, so all of them are in PEM format) to get the total ASN.1-format length of the DNs (which is how they get sent over the wire during the handshake), and thereby see if I'm getting too close to the limit. I haven't yet been able to find a way to do this, though: the OpenSSL asn1parse function comes close, but it doesn't seem to provide a way to get the ASN.1 sequence for just the issuer name, which is what I need.

Any suggestions?

Answer 1

Since ASN.1 is self describing, it's fairly easy to write an ASN.1 parser. As you probably know, ASN.1 data contains a tree of values, where each value type is identified by a globally assigned OID (Object ID). You can find a free ASN.1 decoder with source code at: http://www.geocities.co.jp/SiliconValley-SanJose/3377/asn1JS.html. It;'s written in javascript so you can play with it directly in your browser.

As to your exact question - I would:

1. Use the supplied parser, find another one or write my own
2. Find the OID of trusted DNs (check the specification or simply decode a certificate using the supplied ASN.1 decoder page)
3. Combine the two above to extract the size of trusted DNs inside a certificate.

Answer 2

openssl asn1parse will do it, but you'll need to do some manual parsing to figure out where the issuer sequence begins. Per RFC 5280, it's the 4th item in the TBSCertificate sequence (potentially 3rd if it's a v1 certificate), immediately following the signature algorithm. In the following example:

    0:d=0  hl=4 l= 621 cons: SEQUENCE
    4:d=1  hl=4 l= 470 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=   1 prim:   INTEGER           :02
   16:d=2  hl=2 l=  13 cons:   SEQUENCE
   18:d=3  hl=2 l=   9 prim:    OBJECT            :sha1WithRSAEncryption
   29:d=3  hl=2 l=   0 prim:    NULL
   31:d=2  hl=2 l=  64 cons:   SEQUENCE
   33:d=3  hl=2 l=  11 cons:    SET
   35:d=4  hl=2 l=   9 cons:     SEQUENCE
   37:d=5  hl=2 l=   3 prim:      OBJECT            :countryName
   42:d=5  hl=2 l=   2 prim:      PRINTABLESTRING   :US
   46:d=3  hl=2 l=  26 cons:    SET
   48:d=4  hl=2 l=  24 cons:     SEQUENCE
   50:d=5  hl=2 l=   3 prim:      OBJECT            :organizationName
   55:d=5  hl=2 l=  17 prim:      PRINTABLESTRING   :Test Certificates
   74:d=3  hl=2 l=  21 cons:    SET
   76:d=4  hl=2 l=  19 cons:     SEQUENCE
   78:d=5  hl=2 l=   3 prim:      OBJECT            :commonName
   83:d=5  hl=2 l=  12 prim:      PRINTABLESTRING   :Trust Anchor
   97:d=2  hl=2 l=  30 cons:   SEQUENCE
   99:d=3  hl=2 l=  13 prim:    UTCTIME           :010419145720Z
  114:d=3  hl=2 l=  13 prim:    UTCTIME           :110419145720Z
  129:d=2  hl=2 l=  59 cons:   SEQUENCE

the Issuer DN starts at offset 31 and has a header-length of two and a value length of 64, for a total length of 66 bytes. This isn't so easy to script, of course...