Matching Subject and Issuer Names

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Matching Subject and Issuer Names

Arsen Hayrapetyan-2
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.

Thank you in advance,
Arsen.


smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Matching Subject and Issuer Names

Dr. Stephen Henson
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 :-)

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                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Matching Subject and Issuer Names

Dr. Stephen Henson
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                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Matching Subject and Issuer Names

Arsen Hayrapetyan-2
Dr. Stephen Henson wrote:
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                    [hidden email]
Automated List Manager                           [hidden email]

  
Thank you for a comprehensive answer. The question arose from the following real-life situation. There is a CA which has the subject name in the following form:
/C=AM/O=xxxxxxx/O=yyyyy/CN=zzzzz

It has to certify the requests with the following subject name:
/O=yyyyy/O=users/O=ddddd/OU=iiiiii/CN=Somebody,
where the first "O=yyyyy" MUST match with second "O=yyyyy" in the CA subject name (they must be identical).

The question was: how to state it in openssl.cnf, that the first "O=..." in user request must match the second "O=..." in CA subject name, and other "O=..." s are to be supplied?

Best regards,
Arsen.

smime.p7s (4K) Download Attachment