On Sat, Jul 02, 2005, Dr. Stephen Henson wrote: > On Sat, Jul 02, 2005, Arsen Hayrapetyan wrote: > > > Hello, > > I have the following question: > > > > Suppose you have CA certificate /cacert.pem/ with the following > > subjectName: > > */C=xx/O=aa/O=bb/CN=uu* > > Also you have the following in your openssl.cnf file (is used when CA > > signs CSRs): > > / > > [ ca ] > > default_ca = CA_default > > > > [ CA_default ] > > ... > > preserve = no # or yes, has no effect during signing procedure :( , I've > > tried > > policy = policy_match > > > > [ policy_match ] > > organizationName = match > > organizationName = match > > organizationName = match > > organizationalUnitName = supplied > > commonName = supplied > > / > > Now you are trying to sign the request (/userreq.csr/) with the > > following subjectName: > > */O=bb/O=bb/O=aa/OU=ff/CN=Somebody > > * > > with the following command: > > /openssl ca -in userreq.csr -policy policy_match -extensions > > user_cert_ext -out newcert.pem > > /(other necessary information is contained in config file) > > > > Openssl (v. 0.9.7a) doesn't complain that in fact the subjectName > > doesn't match the pattern described in config file! First two *O=bb > > *both has been matched (why?) > > Can anybody describe the algorithm which openssl uses when it matches > > subjectName in CSR against subjectName in CACERT? Or refer me to some > > source of information. > > > > Well apps/ca.c can describe the algorithm :-) > > It is a limitation of the configure file format that if the same name field > appears multiple times in the same section only the last one is recognized. > > Normally there's a workaround where a prefix or suffix can be used such as > 1.O, 2.O etc, however no workaround has been added to the ca.c policy matching > stuff so this can't be done... well not yet anyway. I'd regard that as a bug. > > Well I suppose you could say O, organizationName and 2.5.4.10 but that's a bit > of a hack :-) >
After examining the code and the way it works it seems that this isn't an easy thing to fix without possible unforseen consequences on existing usage. This close to a release I'd rather not try to rewrite the algorithm. I'll place redoing that algorithm on my list of things to do. It could do with an overhaul anyway with some new features. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
