Pluto Liu wrote:
>
>
> And I found the certificates(my.pem&my2.pem) are different at column 11.
> diff my.pem my2.pem
> 11c11
> < AaATFhEzNDcwMDAwMDBOQFRFU1QwMKNaMFgwCwYDVR0PBAQDAgeAMAkGA1UdEwQC
> --- ~
> > AaATFhEzNDcwMDAwMDBOQFRFU1QwM6NaMFgwCwYDVR0PBAQDAgeAMAkGA1UdEwQC
>
> They have different fingerprint when i view they in windows environment.
>
> But like Steve says,they really have the same fingerprint in openssl function.
> (fingerprint is 6BE5 C3AC 6EC6 7D44 07F8 175B 2C7D 599E CB4D E8AE)
>
> I wonder if the openssl's canot parse some field of my certificate??
>
> I put the origin certificates(root.cer&my.cer) and the certificates transforming
> by openssl(my.pem) and mmencode command(my2.pem&root2.pem) in the url:
> http://yeahsun.csie.nctu.edu.tw/~pluto/certs.zip
>
I've examined the certificates in detail and found several problems with
it.
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.
--
Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED]
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
