Thank you for the suggestion. Alas, I had already learned that the requested password was for the master store and not the certificate; that is the password I was using - John
On Mon, 2005-05-23 at 11:17 +0200, Alfonso Sparano wrote: > Hi John > perhaps your problem in signing process is that you should use the firefox > master password for software security device and not the password of your > certificate. > > Best regards, > Alfonso Sparano > > > -----Messaggio originale----- > Da: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Per conto di John A. > Sullivan III > Inviato: sabato 21 maggio 2005 19.48 > A: [email protected] > Oggetto: Re: [Openca-Users] RA not downloading CA certs from CA? > > 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_id=7412&alloc_id=16344&op=click _______________________________________________ Openca-Users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openca-users
