On Thu, 2009-01-15 at 19:54 -0500, John A. Sullivan III wrote:
> On Thu, 2009-01-15 at 15:00 -0500, John A. Sullivan III wrote:
> > Hello, all. I've heard some discussion of people using OpenCA with
> > domain components instead of O= C=. We've gotten most of that working
> > but have a problem where whatever routine is parsing the input from the
> > browser_req.xml generated form is setting both values to the first dc
> > setting. To clarify, I am allowing the cert requester to choose the
> > domain components from a drop down rather than appending the base rdn
> > values. This is for a multi-client environment where not everyone is
> > dc=mycompany,dc=com.
> >
> > As a result, when they fill in something like dc=ssiservices,dc=biz, the
> > CSR comes out as dc=ssiservices,dc=ssiservices. I'm having the same
> > problem with allowing multiple ou fields on the form.
> >
> > I suspect the problem was that the names of the html fields were the
> > same (duh!) so I changed the names to something like dc_1 and dc_2 and
> > tried adding the <valueType> tag, e.g., <valueType>dc</valueType> to
> > such fields. I thought that would be the solution for sure and was
> > thrilled when the DN displayed properly on the confirmation page but,
> > alas, I received an error when generating the CSR:
> >
> > (OpenCA::REQ->new: Cannot create new request. Backend fails with
> > errorcode 7712013. OpenCA::OpenSSL->genReq: Cannot build X500::DN-object
> > from subject CN=nopub2, OU_1=OfficeUsers, DC_1=ssiservices, DC_2=biz)
> >
> > It appears the parser is indeed using the name tag to determine the
> > field type! Of course, this creates a problem anytime there are multiple
> > inputs for the same field type. Has anyone cracked this problem? Can
> > anyone point me to where in the code the dn is compiled? I've looked in
> > OpenCA::REQ and that seems to take input from elsewhere, maybe
> > create_csr.sub but that is getting the subject from a file /data/SUBJECT
> > and I've yet to find out where that is made. HELP!!! Thanks - needed
> > to do that :) - John
>
> I really don't know what I'm looking at as I don't know perl but I'm
> guessing the browser_req.xml file is parse by the genInputXML subroutine
> of request-utils.lib. This appears to be called from advanced_csr at
> around line 619. I made the following changes starting at line 619 in
> my copy and it appears to be working:
>
> my $dn = "";
> foreach my $item
> ($reqTwig->get_xpath("request/certificate/dn/input")) {
> my $name = getField( $item, "name" );
> my $vtype = getField( $item, "valueType" );
> if( (! defined $vtype) or $vtype eq "" ) {
> $vtype = $name;
> }
> my $val = $query->param( "$name" );
>
> if( $dn ne "" ) {
> $dn .= ", ";
> }
>
> # $name =~ s/^\s+//g;
> $vtype =~ s/^\s+//g;
>
> $val =~ s/\\/\\\\/g;
> $val =~ s/,/\\,/g;
> $val =~ s/=/\\=/g;
> $val =~ s/\+/\\+/g;
>
> # if ( $name =~ /cn|ou|o|l|c|sn|uid/i ) {
> # $name = uc ($name);
> if ( $vtype =~ /cn|ou|o|l|c|sn|uid/i ) {
> $vtype = uc ($vtype);
> }
>
> # $dn .= uc($name) . "=$val";
> $dn .= uc($vtype) . "=$val";
> }
> $dn =~ s/^\s+//g;
>
> PLEASE DO NOT USE THIS PATCH UNLESS YOU CAN VALIDATE IT DOES WHAT IT IS
> SUPPOSED TO DO!!!!!!!!!!!! I don't know a thing about Perl. I made
> these changes by guessing at the syntax from the rest of the file and
> thumbing through the O'Reilly Programming Perl book (which I have never
> read). It may be catastrophic and foolish. I will wrap it up in a patch
> and send it to the developers.
>
> If anyone can validate or correct this patch, it would be GREATLY
> appreciated. Thanks - John
<snip>
Oops! That's what I get for being in a hurry! I forgot to mention how to
use this patch. I borrowed the valueType tag from the subjectAltName
logic. If one does not have a valueType tag defined in browser_req.xml,
it will pass the name tag value into the dn. This preserves all the
existing configurations. However, if you have multiple OU or DC fields,
you cannot have two input fields both named DC. Thus, you can use
something like DC_1 and DC_2 for the name tags but add a valueType tag
with value DC. Here is a snippet from my test browser_req.xml file:
<input>
<name>cn</name>
<label>Subject Name</label>
<type>textfield</type>
<charset>UTF8_LETTERS</charset>
<value>$ADDITIONAL_ATTRIBUTE_UID</value>
<minlen>2</minlen>
<required>YES</required>
</input>
<input>
<name>ou_1</name>
<label>Certificate Group 1</label>
<type>select</type>
<charset>UTF8_MIXED</charset>
<value>OfficeUsers</value>
<value>Engineers</value>
<value>HelpDesk</value>
<value>Operators</value>
<value>VPNGateways</value>
<value>WebServers</value>
<minlen>2</minlen>
<required>YES</required>
<valueType>OU</valueType>
</input>
<input>
<name>ou_2</name>
<label>Certificate Group 2</label>
<type>select</type>
<charset>UTF8_MIXED</charset>
<value></value>
<value>OfficeUsers</value>
<value>Engineers</value>
<value>HelpDesk</value>
<value>Operators</value>
<value>VPNGateways</value>
<value>WebServers</value>
<minlen>0</minlen>
<required>NO</required>
<valueType>OU</valueType>
</input>
Note how the cn element does not use a valueType tag and thus uses the
name value for the dn whereas I have two OU inputs named ou_1 ad ou_2
which do use the valueType tag to tell the dn parser that this is an OU
element. As always, looking for suggestions to do this better - John
--
John A. Sullivan III
Open Source Development Corporation
Street Preacher: Are you SAVED?????!!!!!!
Educated Skeptic: Saved from WHAT?????!!!!!!
Educated Believer: From our selfishness that hurts the ones we love
and condemns us to an eternity of hurting each other.
http://www.spiritualoutreach.com
Christianity that makes sense
------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Openca-Users mailing list
Openca-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openca-users
