Hi Guys, Here's a question for the experts....
and before you ask the reason why we want to do it is because it's a good idea.... We have a new business naming scheme that looks like this: "McDonalds@tampa(fl-us)" where McDonalds is the business name, tampa is the town, fl is the state code and us is the country. How is the best way to build certificates for this naming scheme ? David Lyon Global TradeDesk www.globaltradedesk.com ----- Original Message ----- From: "Michael Bell" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, April 16, 2002 5:26 PM Subject: Re: Wrong DNs > Vadim Fedukovich schrieb: > > > > 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). > > What do you want to say with this answer? The problem has nothing to do > with signature verification. If you use "openssl x509" or any other > openssl command then you will see a DN. The question is, why is the > order (in which the DN is displayed) different from the one used for > LDAP. Use X.500 the opposite order of LDAP? > > Michael > -- > ------------------------------------------------------------------- > Michael Bell Email (private): [EMAIL PROTECTED] > Rechenzentrum - Datacenter Email: [EMAIL PROTECTED] > Humboldt-University of Berlin Tel.: +49 (0)30-2093 2482 > Unter den Linden 6 Fax: +49 (0)30-2093 2959 > 10099 Berlin > Germany http://www.openca.org > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > Development Mailing List [EMAIL PROTECTED] > Automated List Manager [EMAIL PROTECTED] > ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
