Copyright (c) 2005 John A. Sullivan III, Atlas Group. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the license can be obtained from http://www.gnu.org/licenses/fdl.txt.

Fedora Core 3 OpenCA Installation with SubCA

Common Preconfiguration:

Each OpenCA computer or VM should have a minimum of 128 MB of RAM.

Our Fedora set up is made on a very bare bones installation of Fedora. Thus, the following packages must be added to meet all OpenCA dependencies:

yum install httpd mod_ssl perl-URI perl-XML-Twig perl-XML-SAX perl-DBD-Pg postgresql postgresql-server postgresql-libs postgresql-pl

Create the openca user and group:

groupadd openca

useradd -g openca -u 1201 openca

Create a /download directory:

mkdir /download

Download the openca-0.9.2.2.tar.gz tarball from http://www.openca.org or from some other source into /download/

Untar the tarball

tar zvxf openca-0.9.2.2.tar.gz

Configure PostgreSQL:

Start the PostgreSQL service with “service postgresql start” to initialize the database.

su to the postgres user, create the openca database, go into psql, create the openca user and assign its password, change the postgres user password:

su - postgres

createdb openca

psql openca

create user openca with password '<the password>'

alter user postgres with password '<the password>'

exit

Edit the postgresql.conf file to allow tcpip connections (/var/lib/pgsql/data/) (tcpip_socket=true)

Edit the pg_hba.conf file (/var/lib/pgsql/data/) so that the access control section looks like this:

local all postgres md5

host openca openca 127.0.0.1 255.255.255.255 md5

local openca openca md5

local all all ident sameuser

Restart the postgresql service so that the changes take effect

As a user other than openca, attempt to open the openca database in psql as openca in order to ensure that the security is configured properly:

psql -U openca openca

The above command should succeed.

Configure httpd:

Edit /etc/httpd/conf/httpd.conf as follows:

ServerName <THE SERVER'S HOSTNAME>:80

DocumentRoot "/usr/local/OpenCA/www/htdocs"

ScriptAlias /cgi-bin/ "/usr/local/OpenCA/www/cgi-bin/"

Edit /etc/httpd/conf.d/ssl.conf by adding the following line to the SSL Global Context section:

SSLOptions +StdEnvVars +ExportCertData

httpd may not start yet as the DocumentRoot directory may not yet be created

Root CA:

The root CA will be a safely stored, non-networked device. It's sole use is to create subCA certificates. As such, it will need an RA and public interface on the same device. Thus, data exchange can happen on the local disk subsystem.

Install interfaces

Since all interfaces will share the same database, no node interface is necessary. We will install the CA, RA and Public interfaces.

Change to the openca source root directory (e.g., /download/openca-0.9.2.2).

./configure --with-openca-user=openca --with-openca-group=openca --with-web-host=$(hostname) --with-httpd-user=apache --with-httpd-group=apache --with-httpd-fs-prefix=/usr/local/OpenCA/www --with-module-prefix=/usr/local/OpenCA/perlmods

make

(make test will probably fail in 0.9.2.2 - we have been told this is not a problem.)

make install-ca && make install-ra && make install-pub

!!!********* OOPS !!! Apparently this won't work. Even though this root RA does not need a node, there is a reference in the code to a file supplied by the node target. Otherwise openca_start fails with an error:

Configuration error: Missing Configuration Keyword : CgiCmdsPath

because etc/servers/common.conf MUST point to node.conf.

Thus we must do:

make install-online && make install-ca

Change to the /usr/local/OpenCA/etc directory and edit config.xml as follows:

General options section

<name>ca_organization</name>

<value>MyOrganization</value>

</option>

<name>ca_locality</name>

</option>

<!--

please enter the ISO country code here

DE, IT, PL, UK, US ...

this country code is ALWAYS two characters long

-->

<name>ca_country</name>

</option>

<name>sendmail</name>

<value>/usr/lib/sendmail -n -t </value>

</option>

<name>send_mail_automatic</name>

</option>

<name>service_mail_account</name>

<value>testrootca@somemail.org</value>

</option>

Database configuration section

<name>dbmodule</name>

</option>

</option>

<value>openca</value>

</option>

<value>localhost</value>

</option>

</option>

<value>openca</value>

</option>

<name>db_passwd</name>

</option>

Module configuration

<name>module_shift</name>

</option>

Dataexchange configuration (at the very end)

<name>dataexchange_device_up</name>

<value>/usr/local/OpenCA/var/tmp/openca-tar</value>

</option>

<name>dataexchange_device_down</name>

<value>/usr/local/OpenCA/var/tmp/openca-tar</value>

</option>

<name>dataexchange_device_local</name>

<value>/usr/local/OpenCA/var/tmp/openca-tar</value>

</option>

Run /usr/local/OpenCA/etc/configure_etc.sh

Initialize the System:

Restart httpd to make sure it is using the edited conf file.

Run openca_start (in /usr/local/OpenCA/etc/)

Point a browser to https://<ROOT CA URL>/ca

username and password are initially root and root

Click on the initialization menu and click Initialize the Certification Authority

Click on initialize database

Click on Generate new CA secret key and take the default values

Click on Generate new CA Certificate Request (use generated secret key) and enter the following values:

E-mail address: <Leave blank>

Common Name: MyTestRootCA

Organizational Unit Name: PKI

Organization: MyOrganization

ISO 3166 Country Code: US

Click on Self Signed CA Certificate (from altready generated request) and set the validity to 7300 days (i.e., 20 years).

Do NOT click on any of the options under Signed by another CA - that is for SubCAs

Click on Rebuild CA Chain

OPEN ENGINEERING ITEM: How to configure access control

Go back to the Initialization menu and click on Create the initial administrator

Click on Create a new request

In the Certificate section, for the name enter CAOperator , for e-mail enter caoperator@somemail.org change the Certificate Request Group to “Trustcenter”. Leave the other certificate section fields blank. These will become the e-mail, CN and OU fields respectively in the subject.

In the User section, leave all fields blank except the following:

Name: CA Operator

Department: Security

Change Level of Assurance to High

Change Role to CA Operator

The RA is the trustcenter itself

Enter an appropriate PIN and confirmation - make a note of what it is

Choose a key size of 1024

Click on continue until the Certificate Request Confirmation (Thank you) page appears.

Return to the Initialization menu and click on Create the initial administrator.

Click on Edit the request

Set the Valid for ## days field to 730 (2 years)

Set the Role to CA Operator

Click on OK

Click on Issue Certificate

Go back to the Initialization menu and click on Create the initial administrator

Do NOT click on Issue the certificate because it has already been issued

Click on Handle the certificate

Change the package to PKCS#12 and download the key pair and cert. It will be used in the browser of the CA Operator.

Import the PKCS#12 package into the CA Operator's browser. To properly sign requests, the browser must not only possess the CA Operator cert and keys and the root CA cert, it must also explicitly trust the CA. This may not happen automatically upon import. For example, this did not happen automatically for me using Firefox on Linux. I needed to go into Firefox Edit/Properties/Advances/”Manage Certificates”/Authorities then click on the root CA - actually the cert underneath the root CA, click on edit and check all three trust boxes (web servers, mail and applications). I did not check to see if I needed all three but web servers alone was insufficient. In production, we will probably want to import this into a browser on the root CA as we will keep that boxed locked in a vault, transfer requests via floppy and only access when certifying a new SubCA.

Go back to the Initialization menu and click on Create the initial RA certificate

Click on Create a new request

In the Certificate section, for the name enter MyTestRootRA, for e-mail enter testrootra@somemail.org and change the Certificate Request Group to “Trustcenter”. Leave the other certificate section fields blank.

In the User section, leave all fields blank except the following:

Name: MyTestRootRA

Department: PKI

Change Level of Assurance to High

Change Role to Web Server

The RA is the trustcenter itself

Enter an appropriate PIN and confirmation - make a note of what it is

Choose a key size of 2048

Click on continue until the Certificate Request Confirmation (Thank you) page appears.

Return to the Initialization menu and click on Create the initial RA certificate

Click on Edit the request

Set the Valid for ## days field to 3700 (just over 10 years)

Set the Role to Web Server

Click on OK

Click on Issue Certificate

We need to ensure that httpd and postgresql start automatically on server boot:

chkconfig httpd on

chkconfig postgresql on

OPEN ENGINEERING QUESTION - I have yet to see where the CA Operator and RA Server certs and keys are used in an all in one CA/RA as we have just created. They may be unnecessary steps. Ah, I do see the need for the CA Operator. When we sign the CSR for the SubCAs, it must be from a browser with the CA Operator's keys and cert.

OPEN ENGINEERING ITEM: We need to set up the CA so that openca_start starts automatically on server boot. There is a proposed script in /usr/local/OpenCA/etc. We need to learn how to use this script.

SubCA:

Go through the common configuration steps outlined at the beginning of this document.

Install the CA:

We have planned to build the SubCAs on Xen unprivileged domains. The creation of the virtual server is outside the scope of this document.

Go to the openca source root directory (/download/openca-0.9.2.2/)

./configure --enable-oscpd --enable-scep --with-openca-user=openca --with-openca-group=openca –with-web-host=$(hostname) --with-httpd-user=apache --with-httpd-group=apache --with-httpd-fs-prefix=/usr/local/OpenCA/www --with-module-prefix=/usr/local/OpenCA/perlmods

make

make install-offline

Change to the /usr/local/OpenCA/etc directory and edit config.xml as follows:

General options section

<name>ca_organization</name>

<value>MyOrganization</value>

</option>

<name>ca_locality</name>

</option>

<!--

please enter the ISO country code here

DE, IT, PL, UK, US ...

this country code is ALWAYS two characters long

-->

<name>ca_country</name>

</option>

<name>sendmail</name>

<value>/usr/lib/sendmail -n -t </value>

</option>

<name>send_mail_automatic</name>

</option>

<name>service_mail_account</name>

<value>testca1@somemail.org</value>

</option>

Database configuration section

<name>dbmodule</name>

</option>

</option>

<value>openca</value>

</option>

<value>localhost</value>

</option>

</option>

<value>openca</value>

</option>

<name>db_passwd</name>

</option>

Module configuration

<name>module_shift</name>

</option>

Dataexchange configuration

It is critical to change the dataexchange template from template 0 to template 1

Comment out the template 0 (XML comments are between  - 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:

<name>dataexchange_device_up</name>

</option>

<name>dataexchange_device_down</name>

</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__@ openca@kbunktestra2.mygroup.net:/usr/local/OpenCA/var/tmp/" "/usr/bin/ssh openca@kbunktestra2.mygroup.net 'sudo chmod 660 @__DEVICE__@;sudo chown apache:openca @__DEVICE__@' " "rm @__DEVICE__@" (the single quotes in the ssh string are very important)

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

"/usr/bin/scp openca@kbunktestra2.mygroup.net:@__DEVICE__@ @__DEVICE__@" "/usr/bin/ssh openca@kbunktestra2.mygroup.net rm -f @__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 openca@kbunktestra2.mygroup.net /bin/tar -tvf @__DEVICE__@"

In all cases, use the appropriate hostname of the RA

The chmod and chown commands will be explained in the RA section.

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.

run /usr/local/OpenCA/etc/configure_etc.sh

Restart the httpd and postgresql services to ensure the changes have taken effect.

run /usr/local/OpenCA/etc/openca_start to start OpenCA.

Initialize SubCA:

Point a browser to https://<SubCA URL>/ca

username and password are initially root and root

Click on the initialization menu and click Initialize the Certification Authority

Click on initialize database

Click on Generate new CA secret key and take the default values

Click on Generate new CA Certificate Request (use generated secret key) and enter the following values:

E-mail address: <Leave blank>

Common Name: MyTestCA1 (or as appropriate)

Organizational Unit Name: PKI

Organization: MyOrganization (or as appropriate)

ISO 3166 Country Code: US (or as appropriate)

Do NOT click on Self Signed CA Certificate as this is not a root CA

Click on Export CA Certificate Request

There is not a process for automatically certifying a subCA from the root CA. In fact, an OpenCA subCA could be certified by a non-OpenCA root CA. Thus, we have several manual steps.

The CSR has been saved in a file named openca-tar wherever we configured the templates to save it.

Copy the tar file to some medium which can be used to eventually transfer the CSR to the root CA. The choice may depend on whether the rootCA is accessible by any means other than floppy. In our test case, the root CA is network accessible and so we will do the following:

Copy the openca-tar file to our home directory

Untar the file:

tar xfv openca-tar

Copy the file to our local computer:

scp root@<IP ADDRESS of SubCA>:/root/careq.pem ~/

Point a browser to https://<RootCA URL>/pub

Click on the User menu then click on Request a Certificate

Click on Server Request

Click on Browse and upload the careq.pem file untarred in the home directory

Set Registration Authority to Trustcenter

Set Role to SubCA

Set Level Of Assurance to High

Enter and confirm an appropriate PIN

Enter an appropriate name, e.g., MyTestCA1

Enter an appropriate e-mail address, e.g., testca1@somemail.org

Set Department to PKI

Click on OK

If the request is correct, click on OK again

Point a browser to https://<RootCA URL>/ra - this must be a browser which has the CA Operator's key and cert in order to sign the request.

Until we change them, user name and password is root and root

Click on the Active CSRs menu and click on New

Set Registration Authority to Trustcenter itself and Level of Assurance to High

Click on search and then click on the hyperlink for the new SubCA request

Click on Edit Request, change the Valid for ## days to 7250 (just under 20 years) and click on OK

Click on Approve Request

I found that the approval dialog is not well designed in that it has no scroll bars. I had to use <Alt> drag to move the dialog up and then expand the window size to expose the OK button. Click on OK. Make sure in the ensuing dialog that the cert and key being used is the CA Operator one. The requested password is the master password for the browser's certificate store and not the password for the private key.

Point a browser to https://<RootCA URL>/ca

Click on the Usual Operations menu and click on Approved Certificate Requests (i.e., it has been approved by the RA - now we need to isue the cert)

Click on the hyperlink for the SubCA CSR

Click on Issue Certificate

Point a browser to https://<RootCA URL>/pub

Click on the Certificates menu and click on Valid

Click on the certificate for the SubCA, leave the format as PEM and download it to our local drive (in production, this might be a floppy)

OPEN ENGINEERING ITEM: I am somewhat dismayed that it downloaded as a text file and displayed in the browser rather than giving me the opportunity to save it to disk. I will cut and paste the text into a cert file but that seems very sloppy. We will need to investigate if there is a better way. In this example, we will call the file subca.pem

We will also need the Cert of the root CA in order to build the trust chain on the SubCA. Click on the CA Infos menu and click on Get CA certificate.

Click on CA certificate in format PEM

OPEN ENGINEERING ITEM: Again it only appears as text in the browser instead of downloading to file so we will have to copy and paste until we find a better way. In this example, we will call the file rootca.crt. The .crt extension is critically important. The root CA cert MUST end in .crt and MUST be in PEM format.

Copy the files from the browser computer to the SubCA root home directory:

scp ~/subca.pem root@<IP ADDRESS>:/root/cacert.pem (the file must be named cacert.pem)

scp ~/rootca.crt root@<IP ADDRESS>:/root/

Verify that the certificates transferred without corruption; the following commands should return the subject without error:

openssl x509 -in cacert.pem -subject -noout

openssl x509 -in rootca.crt -inform pem -subject -noout

tar the cert to the data receive directory

tar -cvf /usr/local/OpenCA/var/tmp/openca-tar cacert.pem

Point a browser to https://<SubCA URL>/ca

Click on the initialization menu and click Initialize the Certification Authority

Click on Initialize the Certification Authority

Click on Import CA certificate ( approved by Root CA )

Move the rootca.crt file to /usr/local/OpenCA/var/crypto/chain/

mv rootca.crt /usr/local/OpenCA/var/crypto/chain/rootca.crt

Click on the initialization menu and click Initialize the Certification Authority

Click on Initialize the Certification Authority

Click on Rebuild CA Chain

RA:

Go through the common configuration steps outlined at the beginning of this document.

Install the RA:

We have planned to build the RAs on Xen unprivileged domains. The creation of the virtual server is outside the scope of this document.

Go to the openca source root directory (/download/openca-0.9.2.2/)

./configure --enable-oscpd --enable-scep --with-openca-user=openca --with-openca-group=openca --with-web-host=$(hostname) --with-httpd-user=apache --with-httpd-group=apache --with-httpd-fs-prefix=/usr/local/OpenCA/www --with-module-prefix=/usr/local/OpenCA/perlmods

make

make install-online

Change to the /usr/local/OpenCA/etc directory and edit config.xml as follows:

General options section

<name>ca_organization</name>

<value>MyOrganization</value>

</option>

<name>ca_locality</name>

</option>

<!--

please enter the ISO country code here

DE, IT, PL, UK, US ...

this country code is ALWAYS two characters long

-->

<name>ca_country</name>

</option>

<name>sendmail</name>

<value>/usr/lib/sendmail -n -t </value>

</option>

<name>send_mail_automatic</name>

</option>

<name>service_mail_account</name>

<value>testra14testca1@somemail.org</value>

</option>

Database configuration section

<name>dbmodule</name>

</option>

</option>

<value>openca</value>

</option>

<value>localhost</value>

</option>

</option>

<value>openca</value>

</option>

<name>db_passwd</name>

</option>

Module configuration

<name>module_shift</name>

</option>

Dataexchange configuration

It is critical to change the dataexchange template from template 0 to template 5

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:

<name>dataexchange_device_up</name>

</option>

<name>dataexchange_device_down</name>

</option>

<name>dataexchange_device_local</name>

<value>/usr/local/OpenCA/var/tmp/openca-tar</value>

</option>

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

Furthermore, there is a problem with ownership of the openca-tar file. When the RA creates it, it is owned by apache:apache and thus the file cannot be deleted or overwritten when the CA needs to because the CA is operating at user openca. When the CA creates it, it is owned by openca:openca creating the same delete and overwrite problem for the RA running as apache. We thus need to change the ownership and rights as part of the export routines. This is further compounded by the fact that the openca and apache users are not normally allowed to chown. Thus we have a two step process. First, we configure sudo so that users apache and openca can chown (we will also sudo chmod in case someone misconfigures the export routines to chown before chmod thus possibly precluding the previous file owner from doing the needed chmod). Second, we edit the node.conf.template file to run the appropriate routines during export.

To configure sudo, run visudo (uses vi style editing commands) and add the following lines to /etc/sudoers :

apache kbunktestra2=NOPASSWD: /bin/chown apache\:openca /usr/local/OpenCA/var/tmp/openca-tar

openca kbunktestra2=NOPASSWD: /bin/chown apache\:openca /usr/local/OpenCA/var/tmp/openca-tar

apache kbunktestra2=NOPASSWD: /bin/chmod 660 /usr/local/OpenCA/var/tmp/openca-tar

openca kbunktestra2=NOPASSWD: /bin/chmod 660 /usr/local/OPenCA/var/tmp/openca-tar

Edit /usr/local/OpenCA/etc/servers/node.conf.template and edit the EXPORT_IMPORT_UP lines as follows:

EXPORT_IMPORT_UP_EXPORT "/bin/tar -cvpf @__DEVICE__@ -C @__SRC__@ ." "sudo chmod 660 @__DEVICE__@" "sudo chown apache:openca @__DEVICE__@"

EXPORT_IMPORT_UP_IMPORT "/bin/tar -xvf @__DEVICE__@ -C @__DEST__@" "rm -f @__DEVICE__@"

They are each one single line.

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 “This account is currently not available.” should appear.

run /usr/local/OpenCA/etc/configure_etc.sh

Restart the httpd and postgresql services to ensure the changes have taken effect.

run /usr/local/OpenCA/etc/openca_start to start OpenCA.

Initialize RA:

Point a browser to https://<RA URL>/ra

username and password are initially root and root

Click on the General menu and click Server Management

Click on the Administration menu and click on Server Init

Click on initialize database

Point a browser to https://<SubCA URL>/ca

Click on the General menu, click on Initialization and click on Create the initial administrator

Click on Create a new request

In the Certificate section, for the name enter MyCAOperator , for e-mail enter mycaoperator@somemail.org and change the Certificate Request Group to “Trustcenter”. Leave the other certificate section fields blank. These will become the e-mail, CN and OU fields respectively in the subject.

In the User section, leave all fields blank except the following:

Name: My CA Operator

Department: Security

Change Level of Assurance to High

Change Role to CA Operator

The RA is the trustcenter itself

Enter an appropriate PIN and confirmation - make a note of what it is

Choose a key size of 1024

Click on continue until the Certificate Request Confirmation (Thank you) page appears.

Return to the Initialization menu and click on Create the initial administrator.

Click on Edit the request

Set the Valid for ## days field to 730 (2 years)

Set the Role to CA Operator

Click on OK

Click on Issue Certificate

Go back to the Initialization menu and click on Create the initial administrator

Do NOT click on Issue the certificate because it has already been issued

Click on Handle the certificate

Change the package to PKCS#12 and download the key pair and cert. It will be used in the browser of the CA Operator.

Go back to the Initialization menu and click on Create the initial RA certificate

Click on Create a new request

In the Certificate section, for the name enter MyTestRA1, for e-mail enter testra1@somemail and change the Certificate Request Group to “Trustcenter”. Leave the other certificate section fields blank.

In the User section, leave all fields blank except the following:

Name: RA14CA1

Department: PKI

Change Level of Assurance to High

Change Role to Web Server

The RA is the trustcenter itself

Enter an appropriate PIN and confirmation - make a note of what it is

Choose a key size of 2048

Click on continue until the Certificate Request Confirmation (Thank you) page appears.

Return to the Initialization menu and click on Create the initial RA certificate

Click on Edit the request

Set the Valid for ## days field to 3700 (just over 10 years)

Set the Role to Web Server

Click on OK

Click on Issue Certificate

Click on the Node Management menu

Click on the Administration menu and click on Dataexchange

Under Enroll data to a lower level of the hierarchy click on All

Click OK when prompted about a support

Point a browser to https://<RA URL>/node

Click the Administration menu and click on Dataexchange

Under Download data from a higher level of the hierarchy click on All

Click OK when prompted about a support

OPEN ENGINEERING ISSUE: There was a problem with the CA chain. We do not yet know if the Dataexchange will properly rebuild the CA chain. If not, we need to copy the rootca.crt file into /usr/local/OpenCA/var/crypto/chain and then run the rebuild certificate chain from the RA node utility menu.

Creating a PKCS#12 Key and Certs package:

Point a browser to https://<RA URL>/pub

Click on the User menu and click Request a Certificate

Click Basic Request

Under Certificate Data, fill in appropriate values for e-mail, name and Certificate Request Group

Fill in appropriate values under User Data

Typically choose a key size of 1024

Click on Continue until arriving at the Thank you success screen

Point a browser to https://<RA URL>/ra

Click the Active CSRs menu and click New

Set Registration Authority as appropriate (in our case Trustcenter itself)

Set Level of Assurance to All

Click on Search

Click on the hyperlink for the CSR

Click on Edit Request

Change any fields as needed and set the Valid for ## days to 365

Click on OK

Click on Approve Request

Click OK in subsequent dialog - the dialog may need to be moved higher on the screen with <Alt> drag and then expanded to reveal the OK button

Click through browser dependent sequence to select key to use for signing - one must have downloaded an RA Operator key and cert into one's browser to perform this function

Click on General and the Server Management or point a browser to https://<RA URL>/node

Click on Administration; click on Dataexchange

Upload All or Requests as appropriate

Point a browser to https://<SubCA URL>/node

Click on Administration; click on Dataexchange

Receive All or Requests as appropriate

Point a browser to https://<SubCA URL>/ca or click on General/Certification Authority

Click on Usual Operations and then on Approved Certificate Requests

Click on the serial number of the approved request

Click on Issue Certificate

Click on Genera/Node Management or point a browser to https://<SubCA URL>/node

Click Administration and then Dataexchange

Enroll All or Certificates as appropriate; click OK on support question

Point a browser to https://<RA URL>/node

Click on Administration and then Dataexchange

Download All or Certificates as appropriate and click on OK to the support question

Click on General/Registration Authority or point a browser to https://<RA URL>/ra

Click on Information, then Certificates then Valid (one may need to scroll the top frame down to see the Valid option)

Click on the serial number of the Certificate

At this point the RA Operator has two major option. They can download the PKCS#12 package themselves and send it to the user or they can set a passphrase so that the user can download it themselves from the public interface. For the sake of illustration, we will choose the latter as it is a bit more complicated

Click on Set Passphrase

Enter an appropriate passphrase

The user then points a browser to https://<RA URL>/pub

Click on Certificates and then Valid

Click on the serial number for the certificate

Change the Certificate and Key Pair option to PKCS#12 and then click Download

Enter the passphrase for the private key

Enter the download passphrase (the passphrase we set when we clicked on Set Passphrase a few steps ago)

Save the package to disk