Installing OpenCA on a SINGLE MACHINE running Red Hat/Fedora/CentOS with
------------------------------------------------------------------------
Apache Web Server and Sendmail installed
------------------------------------------------------------------------

0. Build and install OpenCA using the build.sh script which installs
both parts of OpenCA (RA and CA) in /usr/local/openra and /usr/local/openca
respectively. (Extract openca-x.y.tar.gz and put build.sh inside openca-x.y
directory. Then change directory to openca-x.y and type ./build.sh )

Enable automatic startup of openca when the machine reboots by installing our
openca script as /etc/init.d/openca as shown below:

cp openca /etc/init.d
chkconfig --add openca

Customize and install openca.conf file as /etc/httpd/conf.d/openca.conf
Restart Apache web server.
Create your site policy file: /usr/local/openra/httpd/htdocs/pub/policy.html
Create your Certification Practice Statement (CPS) file:
/usr/local/openra/httpd/htdocs/pub/cps.html

Edit loa.xml files to make sure CPS.1 points to this correct CPS location:
sed -i 's|http://some.url.org/cps|http://pki.acme.com/cps.html|g' \
/usr/local/openca/openca/etc/loa.xml /usr/local/openra/openca/etc/loa.xml

1. Edit /usr/local/openca/openca/etc/config.xml (for CA) and
/usr/local/openra/openca/etc/config.xml (for RA)

Choose appropriate section below 'dataexchange configuration' line in each of
these two files as shown below.

CA: config.xml: node acts as a CA only
dataexchange_device_up: Replace /dev/fd0 by /usr/local/openca/openca/var/tmp/ca-up
dataexchange_device_down: Replace /dev/fd0 by /usr/local/openca/openca/var/tmp/ca-down
dataexchange_device_local: Replace /dev/fd0 by /usr/local/openra/openca/var/tmp/ra-local

RA: config.xml: node acts as an RA only
dataexchange_device_up: Replace /dev/fd0 by /usr/local/openca/openca/var/tmp/ca-down
dataexchange_device_down: Replace /dev/fd0 by /usr/local/openra/openca/var/tmp/ra-down
dataexchange_device_local: Replace /dev/fd0 by /usr/local/openra/openca/var/tmp/ra-local

NOTE: 
i.  dataexchange_device_up value in config.xml of RA is the same as
dataexchange_device_down value in config.xml of CA. 
ii. dataexchange_device_local value is the same in config.xml of CA and of RA

2. Verify that your sendmail works properly

First, find out your sendmail value:
grep -w sendmail /usr/local/openca/openca/etc/config.xml
grep -w sendmail /usr/local/openra/openca/etc/config.xml

The default value: /usr/lib/sendmail -n -t

Next, search for <name>service_mail_account</name> in 
/usr/local/openca/openca/etc/config.xml or
/usr/local/openra/openca/etc/config.xml and note its corresponding value, ie,
the one enclosed in <value> and </value>. Set this value as your $sender

For example:
sender=pki@yourdomain.com

Now, test and make sure that your sendmail value, when invoked as follows,
works properly. Supply a test email account below and make sure you receive the
test message in your test email account.

cat << END | sendmail -n -t
From: $sender
To: testemailaccount@yourdomain.com
Subject: test

Helo
This is test
.
END

3. Enable automatic emails for CA and RA.

In both files:
/usr/local/openra/openca/etc/config.xml (for RA) and
/usr/local/openra/openca/etc/config.xml (for CA),
locate entry <name>send_mail_automatic</name> and set value for this entry to
yes

4. Change password for root login through web interace for RA

cd /usr/local/openra
./bin/openca-digest sha1 'mypasswd'
(Enclose password string in single quotes)
(Write down the generated hash, not the password, in a safe place)

cd /usr/local/openra/openca/etc/access_control

Replace ALL occurances of default hash (enclosed in <digest></digest>) with
this new generated hash in all files that contain it:
vi `grep -li '<digest>' *.template`

NOTE: Although we replaced default hash with our new hash in pub.xml.template,
it is commented out by default. Normally, this is fine as we want everyone to
be able to access public interface (https://hostname/pub). But if you want to
restrict access, you have to uncomment the appropriate block in
pub.xml.template.

5. Change password for root login through web interface for CA

cd /usr/local/openca
./bin/openca-digest sha1 'mysecret'
(Enclose password string in single quotes)
(Write down the generated hash, not the password, in a safe place)

cd /usr/local/openca/openca/etc/access_control

Replace ALL occurances of default hash (enclosed in <digest></digest>) with
this new generated hash in all files that contain it:
vi `grep -li '<digest>' *.template`

NOTE: Although these steps show that we are using the same password, it is a
good idea to use different passwords for different *.template files. In fact,
it is strongly recommended to use a unique and strong password for *.template
files belonging to CA.

6. Disable Logout button for pub interface (for RA)

As explained in the NOTE in item 4 above, pub interface (https://hostname/pub) 
is not protected by password. If you changed this default behavior and chose
to enable password protection, skip this step.

vi /usr/local/openra/openca/etc/menu.xml.template
Locate <interface><name>@pub_prefix@</name> first.
Once you located this block, look for sub-block titled <name>General</name>.
Inside that, you will see <name>Logout<name> section.
Change Logout to 'Not logged in' (without quotes),
Delete the value for <link> so it looks: <link></link> and
Change _top to main for <target> field.

7. Create necessary config files from templates and start processes for RA

cd /usr/local/openra/openca/etc
./configure_etc.sh
./openca_start

Test from browser:

https://hostname/ra
https://hostname/ra-node
https://hostname/pub

8. Create necessary config files from templates and start processes for CA

cd /usr/local/openca/openca/etc
./configure_etc.sh
./openca_start

Test from browser:

https://hostname/ca
https://hostname/ca-node

9. Web based configuration for https://hostname/ca

On page:
General -> Initialization -> Phase I (Initialize the Certification Authority)
Do:
	-> Initialize Database

	-> Generate new CA secret key

	-> Generate new CA Certificate Request (use generated secret key)
	(Fill in the form, use same email for sender thats used in config.xml)

	-> Self Signed CA Certificate (from altready generated request)
	(Accept defaults)

	-> Rebuild CA Chain

On page:
General -> Initialization -> Phase II (Create the initial administrator)
Do:
	-> Create a new request
	(Fill in the form and generate csr for CA Administrator)

	-> Edit the request
	(Optional)

	-> Issue the certificate

	-> Handle the certificate
	(Certificate and Keypair, PKCS#12, click Download. Save as caadmin.p12)
	(Doubleclick on caadmin.p12 and import into browser. Restart browser)

On page:
General -> Initialization -> Phase III (Create the initial RA certificate)
Do:
	-> Create a new request
	(Fill in the form. Change Role to RA Operator. Generate csr for RA Op)

	-> Edit the request
	(Optional)

	-> Issue the certificate

	-> Handle the certificate
	(Certificate and Keypair, PKCS#12, click Download. Save as raop.p12)
	(Doubleclick on caadmin.p12 and import into browser. Restart browser)

10. Sychronize configuration between CA and RA

First, enroll 'Configuration' from ca-node as follows:

Go to https://hostname/ca-node
Click on Administration -> Dataexchange
Click on Enroll data to a lower level of the hierarchy -> Configuration

Next, download 'Configuration' on ra-node as follows:

Go to https://hostname/ra-node
Click on Administration -> Dataexchange
Click on Download data from a higher level of the hierarchy -> Configuration

11. Synchronize everything between CA and RA

First, enroll 'All' from ca-node as follows:

Go to https://hostname/ca-node
Click on Administration -> Dataexchange
Click on Enroll data to a lower level of the hierarchy -> All

Next, download 'All' on ra-node as follows:

Go to https://hostname/ra-node
Click on Administration -> Dataexchange
Click on Download data from a higher level of the hierarchy -> All
(Ignore warnings, if any)

12. Issue the first client certificate for testing

Generate Certificate Signing Request (csr) on PUB
Go to https://hostname/pub
User -> Request a Certificate -> Request a cert with automatic browser detection
Fill in the form. Write down the serial number. This is Request's Serial Number.

Approve the request
Go to https://hostname/ra
Active CSRs -> New -> Search
Click on serial number
Click on Approve Request without signing

Export the request from RA
Go to https://hostname/ra-node
Admin -> dataexchange -> Upload data to a higher level -> requests

Import the request on CA
Go to https://hostname/ca-node
Admin -> dataexchange -> Receive data from a lower level -> requests

Issue the certificate
Go to https://hostname/ca
Usual Operations -> Approved Certificate Requests
Click on serial number and then click Issue certificate button

Export the certificate from CA
Go to https://hostname/ca-node
Admin -> dataexchange -> Enroll data to a lower level -> Certificates

Import the certificate on RA
Go to https://hostname/ra-node
Admin -> dataexchange -> Download data from a higher level -> Certificates

Pick up the certificate on PUB
Go to https://hostname/pub
User -> Get Requested Certificate
Use the install button (must supply Request's Serial Number)
Or, click on Certificates -> valid to download the certificate

13. Issue new CRL

Now, as an owner of the above test certificate, submit CRR (certificate
revocation request) to revoke your test certificate. After that, you should
login to RA, approve the CRR without signing and then upload to CA from ra-node
and then download to CA from ca-node. After that approve CRR from CA interface.

Go to https://hostname/ca
Usual Operations -> Issue new CRL

After issuing new CRL from CA interface, you should login to ca-node interface
and enrol to RA, then login to ra-node and download the same CRL.

This creates and posts a new CRL. Its a good idea to issue a new CRL before
issuing real certificates because several clients, for example Outlook, try
to obtain CRL (from URLs published in CDPs, certificate distribution points)

14. We now issued a test User role certificate and tested that it can be
revoked. We also issued and posted new CRL. We are now ready to use our OpenCA
for issuing real certificates for production purposes.

15. Backup important files

mkdir /root/opencafiles
cd /root/opencafiles
cp /usr/local/openca/openca/etc/config.xml ca.config.xml
cp /usr/local/openra/openca/etc/config.xml ra.config.xml
cp /usr/local/openra/httpd/htdocs/pub/cps.html cps.html
cp /usr/local/openca/openca/etc/loa.xml ca.loa.xml
cp /usr/local/openra/openca/etc/loa.xml ra.loa.xml
cp /etc/httpd/conf.d/openca.conf openca.conf
cp /etc/init.d/openca openca
cp /usr/local/openra/httpd/htdocs/pub/policy.html policy.html

Note: In a sane configuration, ca.loa.xml and ra.loa.xml must be
identical files. So, we can just name it loa.xml in our backup directory.

16. Restore config files

You can copy the following files in our backup as shown below to restore OpenCA
configuration. But before you copy these files directly, please customize them
(for example: change Acme by your company name). See below for a list of 
customizable terms.

ca.config.xml -> /usr/local/openca/openca/etc/config.xml
ra.config.xml -> /usr/local/openra/openca/etc/config.xml
cps.html      -> /usr/local/openra/httpd/htdocs/pub/cps.html
loa.xml       -> /usr/local/openca/openca/etc/loa.xml
loa.xml       -> /usr/local/openra/openca/etc/loa.xml
openca.conf   -> /etc/httpd/conf.d/openca.conf
openca        -> /etc/init.d/openca
policy.html   -> /usr/local/openra/httpd/htdocs/pub/policy.html

Customizable Terms used in the above files:

Acme Inc	-> Fictitious company
AcmeCA		-> CA for the fictitious company
Acme		-> Short name for the fictitious company
pki.acme.com	-> hostname on which we are installing OpenCA
pki@acme.com	-> Email sender address for all emails from the CA
https://web.acme.com/logo.gif -> location of Acme logo

--------------------------------------------------------------------------