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
