Hello, all. I realize I'm top posting but that is how this thread
developed. Here is what we have done so far to compensate for not
running node dataexchange and using a single shared database instead:
>From our internal documentation:
The OpenCA installation routine for the CA/RA does not properly make the
symbolic links for downloading the latest CRL and CA cert so we will do
this manually.
cd /opt/OpenCA/www/html/pki/ra
mkdir crl
mkdir cacert
cd crl
ln -s ../../../../../var/openca/crypto/crls/cacrl.crl cacrl.crl
ln -s ../../../../../var/openca/crypto/crls/cacrl.der cacrl.der
ln -s ../../../../../var/openca/crypto/crls/cacrl.pem cacrl.pem
ln -s ../../../../../var/openca/crypto/crls/cacrl.txt cacrl.txt
cd ../cacert
ln -s ../../../../../var/openca/crypto/cacerts/cacert.cer cacert.cer
ln -s ../../../../../var/openca/crypto/cacerts/cacert.crt cacert.crt
ln -s ../../../../../var/openca/crypto/cacerts/cacert.der cacert.der
ln -s ../../../../../var/openca/crypto/cacerts/cacert.pem cacert.pem
ln -s ../../../../../var/openca/crypto/cacerts/cacert.txt cacert.txt
cd ..
chown -R openca:openca c{acert,rl}
cd ../ca
mkdir crl
mkdir cacert
cd crl
ln -s ../../../../../var/openca/crypto/crls/cacrl.crl cacrl.crl
ln -s ../../../../../var/openca/crypto/crls/cacrl.der cacrl.der
ln -s ../../../../../var/openca/crypto/crls/cacrl.pem cacrl.pem
ln -s ../../../../../var/openca/crypto/crls/cacrl.txt cacrl.txt
cd ../cacert
ln -s ../../../../../var/openca/crypto/cacerts/cacert.cer cacert.cer
ln -s ../../../../../var/openca/crypto/cacerts/cacert.crt cacert.crt
ln -s ../../../../../var/openca/crypto/cacerts/cacert.der cacert.der
ln -s ../../../../../var/openca/crypto/cacerts/cacert.pem cacert.pem
ln -s ../../../../../var/openca/crypto/cacerts/cacert.txt cacert.txt
cd ..
chown -R openca:openca c{acert,rl}
Since we are not using the node, we need a way to transfer the latest
cacert and crl to the pub node. We will do this via key based SSH thus
we need to generate a key for the CA root user:
ssh-keygen -t rsa (take the default location and do not enter a passphrase)
Create a bash script named pkitransfer in the CA /etc/init.d directory
to copy the needed files to pub. Here is the script:
#!/bin/bash
# chkconfig: 2345 99 01
# description: Transfers latest cacert and crl to pub node
CRYPTO=/opt/OpenCA/var/openca/crypto/
cd ${CRYPTO}
scp cacerts/ca*.{pem,der,txt} pi:${CRYPTO}cacerts/
scp crls/cacrl.* pi:${CRYPTO}crls/
#ssh does not do shell expansion hence the explicit calls
ssh pi "cd /opt/OpenCA/var/openca/crypto;chown -R apache:apache cacerts;chown
-R apache:apache crls"
if [ ${1} = "stop" ];then
rm -f /var/lock/subsys/pkitransfer
# killall will rerun the script if the lock file is not removed
else
touch /var/lock/subsys/pkitransfer
# the script will not run on shutdown if there is no lock
fi
Make the script executable and make it run on startup and shutdown
chmod 750 /etc/init.d/pkitransfer
chkconfig --add pkitransfer
Hope this helps someone else. If anyone has any suggestions for
improvement or anything we missed by not doing node dataexchange, please
send them to me. By the way, the var/lock/subsys issue is why the
openca init script does not properly shutdown on RedHat style systems -
at least it didn't on our CentOS 5.2. Thanks - John
On Tue, 2008-12-16 at 10:18 -0500, David W Blaine wrote:
>
> Yes manually create the links as you specified. Only have to do this
> once. Hopefully Max fixes this in the next rev.
>
> In order to issue the new CRL you will have to bring up the CA
> interface. So in this process, you'll have to manually copy the new
> files on the filesystem over to the new machine and volume (perhaps
> you can even automate this through SSH or NFS when it happens via code
> modifications).
>
> Unfortunately I don't know the answer to your last question. Perhaps
> the OpenCA gods will smile on you and give you a better answer.
>
> -----------------------------------------------------------------
> DAVID BLAINE, GCIA , CISSP
> GDLS-C Lead Information Risk Manager (LIRM)
> CSC
>
> 6000 E. 17 Mile Rd. Sterling Heights MI 48313
> GIS | o: 586.825.7650 | c: 810.217.8041 | f: 586.825.8606 |
> dblai...@csc.com | www.csc.com
>
<snip>
> "John A. Sullivan III"
> <jsulli...@opensourcedevel.com>
>
> 12/16/2008 10:15 AM
>
>
> To
> David W
> Blaine/GIS/c...@csc
> cc
> "Users' Help and
> Suggestions"
> <openca-users@lists.sourceforge.net>
> Subject
> Re:
> [Openca-Users]
> Can't find CRL
> (was Re: Shared
> database)
>
>
>
>
>
>
>
> Thank you, David. This helps a lot but leaves a few questions. I
> assume I can work around the bug by creating the links manually. Are
> these links from www/html/pki/pub/crl to var/openca/crypto/crls etc.?
>
> You mention that every time the CRL is updated, the file system is
> updated. I assume that means that when the CA issues a new CRL, the
> latest crl is placed in var/openca/crypt/crls/cacrl.pem on the CA. If
> we are not using dataexchange through the node (the reason for using a
> shared database, how will these files get to the file system on the
> pub
> server (a different host and hence a difference file system)?
>
> Is there anything else that is short circuited by not using the node
> dataexchange? Thanks - John
>
> On Tue, 2008-12-16 at 08:45 -0500, David W Blaine wrote:
> >
> > Hi John,
> >
> > The answer to you first question (and probably the rest since they
> all
> > seem to follow from this basic question): Yes the CRL's (as well as
> CA
> > certs at least in the PUB interface) are grabbed from the
> filesystem.
> > There is a bug in OpenCA 1.0.2 where the links from the
> > $OPENCA_HOME/openca/var/crypto are not created in the PUB interface.
> > Everytime the CRL is generated the filesystem is updated so if you
> > have links (instead of actual file copies) all will be up-to-date.
> >
> >
> > -----------------------------------------------------------------
> > DAVID BLAINE, GCIA , CISSP
> > GDLS-C Lead Information Risk Manager (LIRM)
> > CSC
> >
> > 6000 E. 17 Mile Rd. Sterling Heights MI 48313
> > GIS | o: 586.825.7650 | c: 810.217.8041 | f: 586.825.8606 |
> > dblai...@csc.com | www.csc.com
> <snip>
> >
> >
> > "John A. Sullivan III"
> > <jsulli...@opensourcedevel.com>
> >
> > 12/15/2008 08:27 PM
> > Please respond to
> > "Users' Help and Suggestions"
> > <openca-users@lists.sourceforge.net>
> >
> >
> >
> >
> > To
> > "Users' Help and
> > Suggestions"
> > <openca-users@lists.sourceforge.net>
> > cc
> >
> > Subject
> > [Openca-Users]
> > Can't find CRL
> > (was Re: Shared
> > database)
> >
> >
> >
> >
> >
> >
> >
> > On Thu, 2008-12-11 at 18:57 -0500, John A. Sullivan III wrote:
> > > On Thu, 2008-12-11 at 18:54 -0500, John A. Sullivan III wrote:
> > > > On Thu, 2008-12-11 at 13:10 -0500, John A. Sullivan III wrote:
> > > > > Hello, all. We have a small, low security client for which we
> > are doing
> > > > > an installation of OpenCA-1.0.2. It is actually an upgrade
> from
> > 0.9.2
> > > > > and a transfer to new equipment. We have already separated
> the
> > RA and
> > > > > CA. The would now like to separate the pub interface from the
> > RA.
> > > > >
> > > > > To avoid having two complete sets of node transfers, I thought
> > we would
> > > > > try using a single shared database and wanted to share my
> > thoughts about
> > > > > both security and how to do this to see if I am making any
> dumb
> > mistakes
> > > > > with this approach.
> > > > >
> > > > > The CA and RA are normally left powered down. This is why
> they
> > would
> > > > > like to separate the Pub - for automated CRL fetching via http
> > as well
> > > > > as for the ease of having some access to the system without
> > having to
> > > > > start up the CA or RA.
> > > > >
> > > > > I was thus thinking of storing a single instance of the
> database
> > on the
> > > > > pub server. My first thought was this is security madness.
> > Then I
> > > > > realized, there is nothing in the database that is not already
> > exposed
> > > > > by the pub interface - keys, certs, crls, reqs - all are made
> > available
> > > > > via pub. Thus, there is no security compromise.
> > > > >
> > > > > FIRST QUESTION:
> > > > > Is this understanding about no security compromise by putting
> > the shared
> > > > > database on the pub server correct?
> > > > >
> > > > > SECOND QUESTION:
> > > > > Is it correct to assume that a shared database eliminates the
> > need for
> > > > > data transfer via the node interface?
> > > > >
> > > > > THIRD QUESTION:
> > > > > Assuming #2 is true, is it correct to assume I still need to
> > install a
> > > > > node on the CA for utility functions like backup, cleanup,
> > rebuild
> > > > > chain, etc.?
> > > > >
> > > > > FOURTH QUESTION:
> > > > > Do I need a node on the other interfaces even with a shared
> > database?
> > > > > For example, the restore procedure on the node not only
> > initializes and
> > > > > restores the database but also rebuilds openssl's database and
> > next
> > > > > serial number. How does one do this on the pub and RA
> > interfaces if
> > > > > there is only a node on the CA? Is it necessary? What about
> > rebuilding
> > > > > the CA chain? Do I need to manually copy in the CA cert and
> hash
> > link to
> > > > > the RA and pub servers?
> > > > >
> > > > > PROCEDURE:
> > > > > I'm assuming I do the following:
> > > > > 1) Setup the database skeleton on the public server
> > > > > 2) Install the CA and CA Node (make install-offline) pointing
> > the
> > > > > database to the database on the public server.
> > > > > 3) Initialize and restore the database and then rebuild the
> > openssl
> > > > > database through the CA node.
> > > > > 4) Install the RA (make install-ra) pointing the database to
> the
> > > > > database on the public server.
> > > > > 5) Manually copy the regular files in the CA's crypto/cacerts
> > directory
> > > > > to the RA's crypto/cacerts directory.
> > > > > 6) Manually copy the files other than Makefile from the CA's
> > > > > crypto/chain directory to the RA's crypto/chain directory.
> > > > > 7) Install the pub interface (make install-pub) pointing the
> > database to
> > > > > localhost.
> > > > > 8) Manually copy the regular files in the CA's crypto/cacerts
> > directory
> > > > > to pub's crypto/cacerts directory.
> > > > > 9) Manually copy the files other than Makefile from the CA's
> > > > > crypto/chain directory to pub's crypto/chain directory.
> > > > > 10) Stand back and watch it all magically work as I create
> > requests in
> > > > > pub, approve them in the RA, issue them in the CA, retrieve
> them
> > from
> > > > > either RA or pub and all without doing a node transfer.
> > > > >
> > > > > FINAL QUESTION:
> > > > > Is this procedure and expected outcome correct?
> > > > >
> > > > > Thanks - John
> > > >
> > > > It looks like the configure_etc.sh calls something which
> requires
> > a
> > > > node.conf. I am assuming that means we need a node even if we
> are
> > using
> > > > a shared database. Is it that the shared database eliminates
> the
> > need
> > > > for data exchange but not the need for the node? Thanks - John
> > > Oops! Forgot to include the error message:
> > > Error while loading configuration
> > > (/opt/OpenCA/RA/etc/openca/servers/node.conf)!Content-type:
> > text/html
> > >
> > <snip>
> > It initially looked as if using the shared database as described
> above
> > was working wonderfully well. It dramatically streamlined the
> > procedure
> > for processing requests. However, we suddenly cannot download the
> > latest CRL or the CA certificate from the pub, ra, or ca interfaces.
> > The
> > results are somewhat disconcerting and may be related to bypassing
> > transfer through the node.
> >
> > I tried retrieving the CRL from the home page of the pub interface.
> I
> > chose the pem format and received a 403 forbidden error. That
> seemed
> > strange. I assumed the latest crl was stored in
> > var/openca/crypto/crls
> > so I looked in that directory and it was empty. I experienced the
> > same
> > results when trying to download the CA certificate.
> >
> > I then tried doing the same from the ra interface and this time
> > received
> > a 404 file not found error. I looked in and it was also empty. My
> CA
> > and RA are on the same server. It also failed when trying from the
> ca
> > interface. I then went to the ca node and enrolled and then
> > downloaded.
> > Now I had files in var/openca/crypto/crls. However, when trying to
> > access them from the ra interface, I still received a 404. The
> files
> > are owned by user and group apache.
> >
> > I copied the crls directory to var/openca/crypto/crls on the pub
> > interface and now I can download the latest crl successfully.
> >
> > This raises several important questions:
> >
> > FIRST QUESTION:
> > It appears the latest crl is not fetched from the database but
> rather
> > from the file system. Is this correct?
> >
> > SECOND QUESTION:
> > Is it really possible to forgo all the node transfers when using a
> > shared database or does one need to do so anyway (which defeats the
> > purpose of the shared database)? On the same subject, can one simply
> > copy the files as I did? In that case, what causes the directories
> on
> > the CA to be populated? Node enrollment?
> >
> > THIRD QUESTION:
> > If one can simply do a copy, what else is done by the node data
> > exchange? In other words, what else do I have to copy and are there
> > any
> > other functions I must perform?
> >
> > We were all set to implement this in production until we hit this
> > issue.
> > Any help to resolve it would be greatly appreciated. Thanks - John
> > --
> > John A. Sullivan III
> > Open Source Development Corporation
> > +1 207-985-7880
> > jsulli...@opensourcedevel.com
> >
> > http://www.spiritualoutreach.com
> > Making Christianity intelligible to secular society
> >
> >
> >
> ------------------------------------------------------------------------------
> > SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas,
> > Nevada.
> > The future of the web can't happen without you. Join us at MIX09 to
> > help
> > pave the way to the Next Web now. Learn more and register at
> >
> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
> > _______________________________________________
> > Openca-Users mailing list
> > Openca-Users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/openca-users
> >
> >
> >
> > This is an e-mail from General Dynamics Land Systems. It is for the
> > intended recipient only and may contain confidential and privileged
> > information. No one else may read, print, store, copy, forward or
> act
> > in reliance on it or its attachments. If you are not the intended
> > recipient, please return this message to the sender and delete the
> > message and any attachments from your computer. Your cooperation is
> > appreciated.
> >
> >
> --
> John A. Sullivan III
> Open Source Development Corporation
> +1 207-985-7880
> jsulli...@opensourcedevel.com
>
> http://www.spiritualoutreach.com
> Making Christianity intelligible to secular society
>
>
--
John A. Sullivan III
Open Source Development Corporation
+1 207-985-7880
jsulli...@opensourcedevel.com
http://www.spiritualoutreach.com
Making Christianity intelligible to secular society
------------------------------------------------------------------------------
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you. Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
_______________________________________________
Openca-Users mailing list
Openca-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openca-users
