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_idt12&alloc_id344&opk _______________________________________________ Openca-Users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openca-users ------------------------------------------------------- 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
