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
--
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
