[OpenCA-Devel] RA not downloading CA certs from CA?

[John A. S. I. <jsu...@op...>]

Hello, all.  I always hesitate to trouble the developers list but the
user list suggested that my problem needed to be escalated.  Here is my
original post to the user list.  Thank you and thank you for your work
on OpenCA.

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.
                       =20
                        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.  In fact, we had the same problem
in an earlier iteration of our test lab where we were using a disk data
exchange.  They were VMs on Xen and used a shared partition.  One node
would mount the partition, write the openca-tar and unmount.  The other
node would then mount and read the openca-tar file.

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 - although I wonder if perl
dependencies aren't our problem here) 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__@
op...@kb...:/usr/local/OpenCA/var/tmp/" "rm
@__DEVICE__@"


and the EXPORT_IMPORT_DOWN_IMPORT line to read (all on one line):

"/usr/bin/scp op...@kb...:@__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 op...@kb... /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 =E2=80=9CThis account is currently not available.=E2=80=9D 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
--=20
John A. Sullivan III
Open Source Development Corporation
+1 207-985-7880
jsu...@op...

If you would like to participate in the development of an open source
enterprise class network security management system, please visit
http://iscs.sourceforge.net