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 ------------------------------------------------------------------------------ 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
