On Sat, 2005-05-21 at 02:32 -0400, John A. Sullivan III wrote: > After what feels like a week of all nighters, we have almost > successfully built our test PKI. But, we've hit another snag. > Openca-0.9.2.2 on fully patched Fedora Core 3 with perl 5.8.5. > > SHORT VERSION: > I generated our first basic request for a PKCS#12 package. Everything > appeared to go fine. I generated the request and edited it. Then I > went to sign it and got: > > Error 700 > General Error The PKCS#7-object signals an > error. The signature is not valid. > > PKCS#7-Error 7932039: OpenCA::PKCS7->parseDepth: > There is a problem with the verification of the > chain. ( error:2:unable to get issuer > certificate) > > That seemed rather strange. Since we do have a root CA and a sub CA and > this RA is servicing the sub CA, I copied the root CA's cert into the > chains directory and ran rebuild certificate chain. All ran without > errors. But this 700 error did not go away. > > I had initialized the RA by downloading all from the CA. So I thought I > would retry just downloading certs. So I successfully enrolled the > certs from the CA. Went to download the certs to the RA and got this > error: > > Importing valid CERTIFICATE ... > Cleaning up the collected import logs ... > WARNING: Cannot update object but object is present in database > FILE: /usr/local/OpenCA/var/tmp/tmp_1510/CERTIFICATE/VALID/1.pem > WARNING: Cannot update object but object is present in database > FILE: /usr/local/OpenCA/var/tmp/tmp_1510/CERTIFICATE/VALID/2.pem > Importing archived REQUEST ... > Cleaning up the collected import logs ... > 8192.pkcs#10 updated > 16384.pkcs#10 updated > > What is going on and how do I fix it? > > > MORE DETAILS FOR THOSE WHO WANT THEM: > Our test environment currently has three PKI servers. We have a > standalone root CA running CA, RA and Pub interfaces. We have a sub CA > and node certified by this root CA running on a Xen VM. There is an > RA/Pub/Node running on a third device which is also a Xen VM. This > services the sub CA. > > I am using Firefox 1.0.4. I imported the initial RA administrator > PKCS#12 packages for both the root CA and sub CA into my browser. > > The root CA uses Data Exchange template 0, the sub CA template 1 and the > RA template 5. Data exchange between the sub CA and the RA is via scp. > We have verified the ssh connection. The CA enrollment returns free of > errors and the openca-tar file arrives successfully on the RA > in /usr/local/OpenCA/var/tmp/ > > The problem appears to be more in reading the openca-tar file once it > arrives rather than transmitting it. Here is an excerpt from the almost > 25 five pages of documentation we have on this setup (including working > out the perl dependencies in Fedora Core 3) describing how we set up the > sub CA data exchange - note that we did have to change some group > ownership and group file system rights to get scp to work - this is > included in these notes: > > > It is critical to change the dataexchange template from template 0 to > template 1 > > Comment out the template 0 (XML comments are between <!-- and --> - be > sure to clean up any stray comment marks that are now syntax errors > because we have placed other comments indicators in the text. > > Uncomment the template 1 section > > Change the very end of the dataexchange configuration section to reflect > the way we will do the scp based data exchange as explained in the > OpenCA docs and the node.conf.template file: > > <!-- these are the devices for the default dataexchange --> > > <option> > > <name>dataexchange_device_up</name> > > <value></usr/local/OpenCA/var/tmp/openca-tar></value> > > </option> > > <option> > > <name>dataexchange_device_down</name> > > <value></usr/local/OpenCA/var/tmp/openca-tar></value> > > </option> > > <option> > > <name>dataexchange_device_local</name> > > <value>/usr/local/OpenCA/var/tmp/openca-tar</value> > > </option> > > > For now, we will handle data exchange via scp as outlined in the OpenCA > documentation. We will allow normal network connectivity and design a > more secure implementation as we move closer to production. > > mkdir /var/www/.ssh > > cd /var/www/.ssh > > Now we generate a new private public key pair for the ssh connection > between CA and RA. When prompted, name the key /var/www/.ssh/id_rsa. > > ssh-keygen -b 1024 -t rsa > > chown -R apache:apache /var/www/.ssh > > > > BEFORE running configure_etc.sh, go to /usr/local/OpenCA/etc/servers and > edit all three template files (ca, node and batch) for scp data > exchange. In each of those files, change the EXPORT_IMPORT_DOWN_EXPORT > line to read (all on one line): > > "/bin/tar -cvpf @__DEVICE__@ -C @__SRC__@ ." "/usr/bin/scp @__DEVICE__@ > [EMAIL PROTECTED]:/usr/local/OpenCA/var/tmp/" "rm > @__DEVICE__@" > > > and the EXPORT_IMPORT_DOWN_IMPORT line to read (all on one line): > > "/usr/bin/scp [EMAIL PROTECTED]:@__DEVICE__@ > @__DEVICE__@" "/bin/tar -xvf @__DEVICE__@ -C @__DEST__@" "rm > @__DEVICE__@" > > > and the EXPORT_IMPORT_DOWN_TEST line to read (all on one line): > > "/usr/bin/ssh [EMAIL PROTECTED] /bin/tar -tvf > @__DEVICE__@" > > In all cases, use the appropriate hostname of the RA > > > If the CA will not be on the network, we will need to provide > an /etc/hosts file for the RA name resolution. We will need to do this > in our test labs, too, as we are not currently using DNS. > > End of excerpt. > > Here is an excerpt on how we set up the RA side: > > > It is critical to change the dataexchange template from template 0 to > template 5 > > Comment out the template 0 (XML comments are between <!-- and --> - be > sure to clean up any stray comment marks that are now syntax errors > because we have placed other comments indicators in the text. > > Uncomment the template 5 section > > Change the very end of the dataexchange configuration section to reflect > the way we will do the scp based data exchange as explained in the > OpenCA docs and the node.conf.template file: > > <!-- these are the devices for the default dataexchange --> > > <option> > > <name>dataexchange_device_up</name> > > <value></usr/local/OpenCA/var/tmp/openca-tar></value> > > </option> > > <option> > > <name>dataexchange_device_down</name> > > <value></usr/local/OpenCA/var/tmp/openca-tar></value> > > </option> > > <option> > > <name>dataexchange_device_local</name> > > <value>/usr/local/OpenCA/var/tmp/openca-tar</value> > > </option> > > > For now, we will handle data exchange via scp as outlined in the OpenCA > documentation. We will allow normal network connectivity and design a > more secure implementation as we move closer to production. > > We cannot scp files as the apache user because the apache user cannot > spawn a shell for security reasons. Thus we will communicate as the > openca user. > > cd /home/openca > > mkdir .ssh > > cd .ssh > > Copy the id_rsa.pub public key from the SubCA /var/www/.ssh directory. > > scp root@<SUBCA>:/var/www/.ssh/id_rsa_1024_openca.pub ./authorized_keys > > chown -R openca:openca /home/openca/.ssh > > The openca user does not normally have rights to write to > the /usr/local/OpenCA/var/tmp directory so we will grant those rights to > the group and change the group to openca (we still must allow the apache > user to write so we cannot change both user and group) > > chgrp openca /usr/local/OpenCA/var/tmp > > chmod 770 /usr/local/OpenCA/var/tmp > > We still have a problem because the openca user is not allowed to enter > the parent var directory. So we will change the group ownership of that > directory, too. > > chgrp openca /usr/local/OpenCA/var > > The apache user on the CA will fail to attach until it has added the > fingerprint for the key to its ssh_known_hosts file. However, the normal > configuration of apache will not allow a shell for security reasons; > thus we cannot attempt a manual connection to save that fingerprint. To > work around this problem, do the following: > > On the SubCA, go to the /etc directory > > edit the passwd file to change the apache user shell from /sbin/nologin > to /bin/bash > > su - apache > > ssh openca@<FQDN (DNS NAME) OF THE RA> > > Answer yes to the fingerprint question > > exit the ssh shell > > exit the bash shell > > edit /etc/passwd to restore the apache user to /sbin/nologin > > Verify that apache can no longer log into a shell by typing su - apache > > A “This account is currently not available.” should appear. > > > > BEFORE running configure_etc.sh, go to /usr/local/OpenCA/etc/servers and > edit all three template files (ca, node and batch) to reflect the > changes for scp data exchange. Actually, they should not need to be > edited because we want the RA to merely write all uploads and read all > downloads from the /usr/local/OpenCA/var/tmp/openca-tar file we > specified in config.xml. The CA will take care of the file transfers via > scp. > > End of excerpt > > Right now we're stuck, frustrated and very, very tired. Any help would > be greatly appreciated. Thanks - John
I should also add that we had a similar problem to the data exchange problem in a previous iteration of our testing. Only that time is was with disk exchange. There was a common partition on our virtual machines. The node would mount the partition, save openca-tar and unmount. The other node would then mount the partition and read the openca-tar file. We had the same messages about the object being in the database but not being able to update it. - John -- John A. Sullivan III Open Source Development Corporation +1 207-985-7880 [EMAIL PROTECTED] Financially sustainable open source development http://www.opensourcedevel.com ------------------------------------------------------- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_idt12&alloc_id344&op=click _______________________________________________ Openca-Users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openca-users
