On Fri, Sep 02, 2005, Christian Weber wrote:
> Hello folks,
>
> i'm sorry but I cannot find the reason for the errors resulting in
> calling openssl (Version 0.9.7e or 0.9.8) as follows:
>
> openssl pkcs7 -noout -text -print_certs < decoded.b64
> unable to load PKCS7 object
> 5655:error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong
> tag:tasn_dec.c:1282:
> 5655:error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1
> error:tasn_dec.c:374:Type=X509_CINF
> 5655:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested
> asn1 error:tasn_dec.c:743:Field=cert_info, Type=X509
> 5655:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested
> asn1 error:tasn_dec.c:704:Field=cert, Type=PKCS7_SIGNED
> 5655:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested
> asn1 error:tasn_dec.c:743:
> 5655:error:0D08403A:asn1 encoding routines:ASN1_TEMPLATE_EX_D2I:nested asn1
> error:tasn_dec.c:572:Field=d.sign, Type=PKCS7
> 5655:error:0906700D:PEM routines:PEM_ASN1_read_bio:ASN1 lib:pem_oth.c:83:
>
> Ca anybody help?
>
The error messsage is giving some help in that it is choking on an X509_CINF
structure within an X509 structure. That hints there's something in a
certificate it doesn't like or what should be a certifcate.
Unfortunately it doesn't currently tell you *where* it is choking in terms of a
file offset. Manually analysing the file using asn1parse...
0:d=0 hl=4 l=2363 cons: SEQUENCE
4:d=1 hl=2 l= 9 prim: OBJECT :pkcs7-signedData
15:d=1 hl=4 l=2348 cons: cont [ 0 ]
19:d=2 hl=4 l=2344 cons: SEQUENCE
23:d=3 hl=2 l= 1 prim: INTEGER :01
26:d=3 hl=2 l= 0 cons: SET
28:d=3 hl=2 l= 11 cons: SEQUENCE
30:d=4 hl=2 l= 9 prim: OBJECT :pkcs7-data
41:d=3 hl=4 l=2320 cons: cont [ 0 ]
That part starting at offset 41 is the certifcate set. By using -strparse 41
that part is output only:
0:d=0 hl=4 l=2320 cons: cont [ 0 ]
4:d=1 hl=4 l= 616 cons: SEQUENCE
8:d=2 hl=4 l= 468 cons: SEQUENCE
12:d=3 hl=2 l= 3 cons: cont [ 0 ]
14:d=4 hl=2 l= 1 prim: INTEGER :02
17:d=3 hl=2 l= 3 prim: INTEGER :32D18D
OK, that bit at offset 4 the first certificate. By adding -strparse 4
and -out cert.der it can be save to a file. Then shoving the result through
the 'x509' utility shows OpenSSL likes it.
The next certificate is at offset 624 (looking for d=1 is the clue here).
624:d=1 hl=4 l= 641 cons: SEQUENCE
628:d=2 hl=2 l= 3 prim: OBJECT :2.5.4.37
633:d=2 hl=4 l= 632 cons: SEQUENCE
637:d=3 hl=4 l= 484 cons: SEQUENCE
641:d=4 hl=2 l= 3 cons: cont [ 0 ]
643:d=5 hl=2 l= 1 prim: INTEGER :02
646:d=4 hl=2 l= 4 prim: INTEGER :01CD4B49
652:d=4 hl=2 l= 10 cons: SEQUENCE
This looks different straight away. Whereas the first has SEQUENCE, SEQUENCE
this starts with that SEQUENCE, OBJECT. That's actually what the problem is.
For some reason whoever generated it has inserted that extra garbage
surrounding the certificate. If that is stripped off and the output starting
at 633 is analysed it is a valid certificate.
That is a violation of PKCS#7 and CMS.
There is also a third certificate in there but it is OK.
Steve.
--
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
OpenSSL project core developer and freelance consultant.
Funding needed! Details on homepage.
Homepage: http://www.drh-consultancy.demon.co.uk
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
