> 1. It uses the (deprecated) subjectUniqueID field, there's nothing
> strictly speaking wrong with that but it is a BIT STRING used to wrap
> another structure, specifically:
>
> 0:d=0 hl=2 l= 28 cons: SEQUENCE
> 2:d=1 hl=2 l= 5 prim: OBJECT :1.2.886.1.1
> 9:d=1 hl=2 l= 19 cons: cont [ 0 ]
> 11:d=2 hl=2 l= 17 prim: IA5STRING :347000000N@TEST00
>
> again there's nothing strictly speaking wrong with that but it is
> encoded incorrectly. The structure starts at the first BIT STRING
> content octet which is actually the number of unused bits. Its for this
> reason that the OpenSSL signature is failing. If it had followed the
> normal rules and set the number of unused bits to 0 and followed that by
> this structure I suspect all would be well as far as the signature is
> concerned.
>
> 2. The root CA has the following extensions:
>
> X509v3 extensions:
> X509v3 Key Usage:
> Certificate Sign, CRL Sign
> X509v3 Basic Constraints:
> CA:FALSE, pathlen:1
> X509v3 Subject Alternative Name:
> 0...0...*.v......CA001
>
> Key Usage says its a CA certificate, Basic Constraints says it isn't a
> CA certificate and the pathlen parameter is set which is illegal if CA
> is FALSE. Even if the signature verified OK software would be justified
> in rejecting the certificate on these grounds alone.
>
> 3. The SubjectAltName extension above looks a bit odd and for good
> reason. It is not encoded properly and the weird output is it just
> printing out the encoding because it couldn't parse it.
>
> The structure in there looks like this:
>
> 0:d=0 hl=2 l= 32 cons: SEQUENCE
> 2:d=1 hl=2 l= 30 cons: cont [ 0 ]
> 4:d=2 hl=2 l= 28 cons: SEQUENCE
> 6:d=3 hl=2 l= 5 prim: OBJECT :1.2.886.1.1
> 13:d=3 hl=2 l= 19 cons: cont [ 0 ]
> 15:d=4 hl=2 l= 17 prim: IA5STRING :347000000N@TEST03
>
> >From RFC2459:
>
>
>
> SubjectAltName ::= GeneralNames
>
> GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName
>
> GeneralName ::= CHOICE {
> otherName [0] OtherName,
> rfc822Name [1] IA5String,
> dNSName [2] IA5String,
> x400Address [3] ORAddress,
> directoryName [4] Name,
> ediPartyName [5] EDIPartyName,
> uniformResourceIdentifier [6] IA5String,
> iPAddress [7] OCTET STRING,
> registeredID [8] OBJECT IDENTIFIER}
>
> OtherName ::= SEQUENCE {
> type-id OBJECT IDENTIFIER,
> value [0] EXPLICIT ANY DEFINED BY type-id }
>
>
> The SEQUENCE OF bit accounts for the outer SEQUENCE. Then we have what
> should be otherName (as specified by the [0] tag) however because its
> IMPLICIT tagging by default the following SEQUENCE shouldn't be there. I
> suspect that this is because it has been incorrectly encoded to use
> EXPLICIT tagging.
>
> Steve.
> --
Thanks for Steve's help.
We will modify our bug following your opinion. :)
Best Regards.
Philip.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
