Boy, I really am tired - this was supposed to go to the developer
mailing list. Sorry for the accidental cross post - John
On Thu, 2009-01-15 at 20:48 -0500, John A. Sullivan III wrote:
> Hello, all. I've been working on cracking the problem of multiple user
> inputs for the same type of field in browser_req.xml, e.g., multiple OU
> or, more typically DC fields and have an attached patch to submit. Here
> is an excerpt from my post to the user's mailing list describing the
> problem:
>
> 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 suspected 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.
>
> 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. 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.
>
> To make it work, 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 for example. 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.
>
> The patch should be copied to common/lib/cmds/ and applied with patch
> -p0 < openca_advanced_csr_multiField-1.0.2.patch
>
> I cannot emphasize enough that I do not know what I am doing and someone
> needs to validate, dismiss, or improve this patch. Thanks for the
> product. Hope this helps - John
> ------------------------------------------------------------------------------
> 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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/openca-users
--
John A. Sullivan III
Open Source Development Corporation
+1 207-985-7880
[email protected]
http://www.spiritualoutreach.com
Making Christianity intelligible to secular society
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/openca-users
