>1.0.0 uses a different algorithm for computing hashes which relies on a form of canonical encoding.
Does that mean we need to recompute the hashes for existing CA certs and CRLs if we are to work with 1.0.0 since it seems to generate a different hash value for the same cert? -Sandeep On Tue, Jan 19, 2010 at 1:55 PM, Dr. Stephen Henson <st...@openssl.org>wrote: > 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 >
