3. Registration Authority Node

The RA Node is the interface used to control RA operations that deal with external interfaces, for example exporting request data to the Certificate Authority.

3.1. General

This section lists the OpenCA components.

3.1.1. Certificate Authority

This link takes the user to the main CA Server page. This link is only available if the CA is accessable. In the normal OpenCA configuration the CA is offline and so this link will fail.

3.1.2. Registration Authority

This link takes the user to the top Registration Authority page.

3.1.3. LDAP Admin

This section takes the user to a screen to manage the LDAP server, if one has been configured.

3.1.4. Public

Pressing this link takes the user to the OpenCA public interface. This interface is described elsewhere in this document.

3.1.5. Logout

Logs the user out of OpenCA.

3.2. Administration

This section lists the options available to configure and maintain the RA Node.

3.2.1. Stop Daemons of Cryto Tokens

If the PKI has been configured with Crypto Tokens holding the CA provate key in an online mode, then this link will stop the token deamon.

3.2.2. Server Init

This screen is used to set up your OpenCA RA. It is intended that the screen be used once and once only. There are two links:

3.2.2.1. Initialise DataBase

The RA Administrator should press this link to run the data base initialisation script. Note if you run this script on an existing data base then you are likely to loose all existing data. Be careful !

3.2.2.2. Import Configuration

This link runs the import process. It requires that a CA export file exists at the appropriate device (or directory). The script will open this file and import the configuration data to the RA.

3.2.3. Dataexchange

This link is used to exchange data with other areas of the PKI infrastructure (e.g. CA). Depending on your implementation of OpenCA, only some of the following sections will apply.

3.2.3.1. Enroll data to a lower level of the hierarchy

It is unlikely that there will be a lower level of the hierachy at the RA.

3.2.3.2. Receive data from a lower level of the hierarchy

It is unlikely that there will be a lower level of the hierachy at the RA.

3.2.3.3. Download data from a higher level of the hierarchy

This section is used to download data from the CA to the RA. In order to use this section, data must have already been exported from the CA. This data is usually stored on a floppy disk. Upon clicking any of the following links the user is prompted "You need to provide a support to proceed (depends on your configuration). Are you sure you want to continue ?". This means that you need to have read access to the device that the exported data is on (e.g. the floppy drive).

3.2.3.3.1. All

Pressing this link imports all the data that has been exported from the CA into the RA.

3.2.3.3.2. Certificates

Pressing this link imports only the certificate data from the CA into the RA.

3.2.3.3.3. CRLs

Pressing this link imports only the CRL data from the CA into the RA.

3.2.3.3.4. Configuration

Pressing this link imports only the configuration data from the CA to the RA. This is data like user roles (certificate types).

3.2.3.3.5. Batchprocessors

Pressing this link imports only the batch processor data from the CA. (**** I don't understand why this is necessary).

3.2.3.4. Upload data to a higher level of the hierarchy

This section enables the RA Administrator to export data to the export device ready for import to the CA. Upon clicking any of the following links the user is prompted "You need to provide a support to proceed (depends on your configuration). Are you sure you want to continue ?". This means that you need to have write access to the device that the exported data going to be written to (e.g. the floppy drive).

Note, the export of data is in the form of a delta, i.e. only new or modified data is exported. It is an administration task to modify this behaviour.

3.2.3.4.1. All

Pressing this link exports all new or modified RA data to the export device.

3.2.3.4.2. Requests

Pressing this link exports all new or modified requests to the export device.

3.2.3.4.3. CRRs

Pressing this link exports all new or modified revocation requests to the export device.

3.2.4. Backup and Recovery

This section allows the RA Administrator to backup and recover the OpenCA RA database. It is good practice to perform a data base backup regularly.

3.2.4.1. Backup Database

Pressing this link backs up the database to the export device. Upon clicking the link, the user is prompted "You need to provide a support to proceed (depends on your configuration). Are you sure you want to continue ?". This means that you need to have write access to the device that the exported data going to be written to (e.g. the floppy drive).

3.2.4.2. Recovery Initialize Database

Pressing this link configures the data base for import of data. If you are rebuilding the RA then it is important to press this link.

3.2.4.3. Restore Database

Use this link to recover the backup data.

3.2.4.4. Rebuild OpenSSL's database and next serial number

In order to issue certificate request numbers to users this link must be pressed so that the OpenCA RA resets it's static configuration data based on the imported data base data.

3.2.5. Database

Use this link to update the searchable attributes in the database after a software update. *** does anyone have a better explanation of this function ?

3.3. Utilites

General utilities for the RA Operator

3.3.1. E-Mail new users

Pressing this link sends the "New User" emails out to new users. These emails tell the users that their certificates are aready for collection and gives them a link to the public interface to collect their certificates.

3.3.2. Send a CRIN-mail

Pressing this link sends new users an encrypted CRIN mail. The CRIN mail contains a pin code that the user must enter when revoking their own certificates. The user should be able to decrypt the message as they would have created the private key during their certificate request process. The message is encrypted using the public key in the certificate request.

3.3.3. Cleanup sessions

I don't know what this does !!!???

3.3.4. Delete Temp Files

This is a link to a housekeeping utility to delete temporary files.

3.3.5. Rebuild CA Chain

This link runs a function that rebuilds the CA Chain, this is useful if your have a CA hierachy and need to tell the environment about the chain of CA certificates.

3.4. Logs

Utilities to handle log files.

3.4.1. Search

This function lets the RA Operator search the log files for log entries of a specific class and level.

3.4.2. Recovery index database

I do not know what this does !!!