On Mon, 15 Apr 2002, Michael Bell wrote: > Hi, > > we found today a big problem with the DNs which OpenSSL displays because > our application (OpenCA) produce DNs which are conform to the > directorystandards but OpenSSL interprets them in the opposite order. > What does this mean? > > Here an example: > > The root of our directory is the following: o=HU, c=de > > The organizational unit for the PKI is Test-CA. So the next DN in the > directory must be: > ou=Test-CA, o=HU, c=de > > A certificate would have the DN "cn=bell, ou=Test-CA, o=HU, c=de". > > It is no problem to produce this DN with OpenSSL but then we were a > little bit shocked when we see the DNs of Thawte, VeriSign, Entrust etc. > with OpenSSL. They have all the format "c=US, o=VeriSign, ..." > (openssl-*/cerst/). All these trustcenters use LDAP-servers but these > DNs can never be stored in a directoryserver! > > So it looks like OpenSSL displays the different parts of a DN in the > wrong order. Did I make a misinterpretation? If this is a bug then I > have the next question, can you fix this in the 0.9.7-tree? > > It is possible to protect the old index.txt etc. by adding an option > -x500 or something like this to get a DN which can be inserted in a > directoryserver. The problem is that OpenSSL interprets a correct DN > with "openssl req -subj 'cn=...,c=de'" in the wrong order (so we get a > "wrong" certificate). > > I know no optimal solution except of adding such an option to every > related command or add an option like -oldstyledn to "openssl x509" and > "openssl ca" but before starting discussing solutions I will wait for an > answer (bug or misinterpretation). > > Best Regards, Michael
Michael, LDAP-style DNs are never of concern while signature verification. Please note LDAP encode names in a different, "lightweight" manner. One may want to use other (non-openssl) tools to manage that encoding (LDAP trees). regards, Vadim p.s One may also add standard bodies did some damage by introducing complex and confusing name handling. This effectively keeps developers out of real crypto, the source of power. Yes, some fair-tales suggest the need to cast real true name of a creature sometimes :) ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
