On Tue, Jan 19, 2010, Colin Phipps wrote:
> We are having trouble using openssl's certificate checking to validate
> certain certificates where certificates in the chain are inconsistent in
> their choice of string encoding.
>
> Using e.g. openssl-0.9.8e-12.el5, the connection in the accompanying
> certificate chain (intermediate cert and final cert only attached) will
> never be made by openssl. I think that this is because the intermediate cert
> has issuer "Government of Korea" (utf8, type 12) but the root cert is
> subject "Government of Korea" (printable, type 19), so it doesn't see this
> intermediate cert as signed by this issuing cert due to the names not
> matching (although they do match semantically, as it were); openssl looks
> for the wrong hash value in the CAdir and, even if I fake up a symlink in
> the CAdir to the right root cert, it doesn't use it.
>
> Internet Explorer accepts the same certificate chain, and presumably that is
> how it is in use in the field (Korea is known for being quite IE-centric, or
> at least it used to be). I have seen this problem on another
> private/governmental CA before but the problem was fixed before I got around
> to looking for solutions.
>
> Have I diagnosed the problem correctly? Is this behaviour by openssl correct
> or incorrect, likely to change, or is it possible to make it work at the
> application level?
>
Changing the encoding does violate a few standards including RFC3280 and
RFC5280 but a few errant CAs exist which do it.
Your analysis of that case is correct. If you use the command:
openssl x509 -in mogaha.pem -subject -issuer -nameopt multiline,show_type
-noout -subject_hash -issuer_hash
You can clearly see the result:
subject=
countryName = PRINTABLESTRING:KR
organizationName = PRINTABLESTRING:Government of Korea
organizationalUnitName = PRINTABLESTRING:GPKI
commonName = PRINTABLESTRING:GPKIRootCA
issuer=
countryName = PRINTABLESTRING:KR
organizationName = PRINTABLESTRING:Government of Korea
organizationalUnitName = PRINTABLESTRING:GPKI
commonName = PRINTABLESTRING:GPKIRootCA
20e6f02d
20e6f02d
Note the two hash values are the same.
Whereas for mogaha_int.pem you get:
subject=
countryName = PRINTABLESTRING:KR
organizationName = UTF8STRING:Government of Korea
organizationalUnitName = UTF8STRING:GPKI
commonName = UTF8STRING:CA134040001
issuer=
countryName = PRINTABLESTRING:KR
organizationName = UTF8STRING:Government of Korea
organizationalUnitName = UTF8STRING:GPKI
commonName = UTF8STRING:GPKIRootCA
610e5e7b
449b326d
You can see here that the string types differ and the second hash value
(issuer) doesn't match those for mogaha.pem.
If you tried getting those hash values with with OpenSSL 1.0.0 or later using:
openssl x509 -in mogaha.pem -subject_hash -issuer_hash -noout
you get this:
mogaha.pem:
11e07c09
11e07c09
mogaga_int.pem
aac725e5
11e07c09
Here you'll see that now the issuer hash matches because 1.0.0 uses a different
algorithm for computing hashes which relies on a form of canonical encoding.
So the best I can suggest is using 1.0.0 which is currently in beta.
For compatibility reasons we can't backport the modified algorithm to 0.9.8.
I think MSIE uses SKID/AKID to build chains if the extensions are present
avoiding DN matching altogether though that can introduce its own problems.
Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
