One problem might be that the X.509 module is using explicit tagging, and
Convert::ASN1 uses implicit tagging. You'll need to hack the ASN.1
definitions you feed into Convert::ASN1 if this is the case. (I didn't know
about the x509decode script; it might do this already..)
However, if I just try calling Convert::ASN1::asn_dump() on $binSan, which
should just do a dump of the ASN.1 structure, I get a runtime error from
perl: Argument "opTYPE" isn't numeric in array element at
/Library/Perl/Convert/ASN1/Debug.pm line 129.
What version do you have ? I just tried it and got
0000 53: SEQUENCE {
0002 51: SEQUENCE {
0004 3: OBJECT ID = 2.5.29.17
0009 44: STRING
000B : 30 2A 82 0C 74 65 73 74 31 2E 68 70 2E 63 6F 6D 0*..test1.hp.com
001B : 82 0C 74 65 73 74 32 2E 68 70 2E 63 6F 6D 82 0C ..test2.hp.com..
002B : 74 65 73 74 33 2E 68 70 2E 63 6F 6D __ __ __ __ test3.hp.com
0037 : }
0037 : }
Graham.
Passing the same data into dumpasn1 decodes OK, so this might be a bug in
Convert::ASN1.
0 53: SEQUENCE { 2 51: SEQUENCE { 4 3: OBJECT IDENTIFIER '2 5 29 17' 9 44: OCTET STRING, encapsulates { 11 42: SEQUENCE { 13 12: [2] 'test1.hp.com' 27 12: [2] 'test2.hp.com' 41 12: [2] 'test3.hp.com' : } : } : } : }
(I'm not sure that it really is an octet string encapsulating stuff, so dumpasn1 could be broken too :-)
Cheers,
Chris
