9. Dataexchange

9.1. Configuration

The dataexchange of OpenCA is highly configurable. So first we have to describe some general concepts.

If you look at OpenCA from a database viewpoint then OpenCA is a tree of hierarchical organized databases. Every database is used by some web interfaces. So one node of the hierarchy consists of a database and some web interfaces. If we describe the dataexchange then we describe the dataexchange between nodes. This is the reason why we called the management interface node.

A node can exchange data with a node of a higher level of the hierarchy or with several nodes which are on a lower level of the hierarchy. If export data to a higher level of the hierarchy then we UPLOAD data and if we import data from such a node then we DOWNLOAD data. If import data from a lower level then we RECEIVE data and if export data to such a node then we ENROLL data.

If you exchange object in a security relevant area then you must define which object with which state you want to exchange. Therefore you can define in OpenCA which objects with which state you accept from which direction. Also OpenCA allows only to overwrite existing objects if you DOWNLOAD CA-certificates, CRLs, CSRs and CRRs. Status or object injections are not accepted in all other situations. OpenCA includes some default configurations to help you on the way to secure configuration.

The following example is for the import from a higher level of the hierarchy:

Example 4.27. Download configuration

DOWNLOAD_CA_CERTIFICATE_STATES VALID
DOWNLOAD_CERTIFICATE_STATES    VALID
DOWNLOAD_CRL_STATES            VALID
DOWNLOAD_CRR_STATES            ARCHIVED DELETED APPROVED
DOWNLOAD_CSR_STATES            ARCHIVED DELETED
DOWNLOAD_MAIL_STATES           CRINS DEFAULT 

The export/import technology itself is another important aspect. You can configure OpenCA to use different methods for the dataexchange with higher and lower levels of the hierarchy. Therefore we implemented options to prepare and cleanup IO operations. This is necessary if you have to start special networkinterfaces or to mount devices. There are also options to configure the EXPORT and IMPORT of the directory with the data and there is an option to TEST the result. EXPORT, IMPORT, START and STOP accept more then one argument. Every argument will be seperately executed. The parameters @__SRC__@ and @__DEST__@ include the directories with the data. The parameter @__DEVICE__@ will be replaced with the value of DEVICE.

Example 4.28. Export configuration

EXPORT_IMPORT_UP_DEVICE "/dev/fd0"
EXPORT_IMPORT_UP_START ""
EXPORT_IMPORT_UP_STOP ""
EXPORT_IMPORT_UP_EXPORT "/bin/tar -cvfp @__DEVICE__@ -C @__SRC__@"
EXPORT_IMPORT_UP_IMPORT "/bin/tar -xvf @__DEVICE__@ -C @__DEST__@"
EXPORT_IMPORT_UP_TEST "/bin/tar -tvf @__DEVICE__@" 

The hierarchylevel LOCAL is used for backups, batchprocessors and such things. It is also possible to configure OpenCA for the use with temporary private networks. Here is another example for a CA:

Example 4.29. Local export configuration

    EXPORT_IMPORT_DOWN_DEVICE "openca.tar"
    EXPORT_IMPORT_DOWN_START "/sbin/ifconfig eth0 up"
    EXPORT_IMPORT_DOWN_STOP "/sbin/ifconfig eth0 down"
    EXPORT_IMPORT_DOWN_EXPORT "/bin/tar -cvfp /usr/local/openca/var/tmp/@__DEVICE__@ -C @__SRC__@" "/usr/bin/scp /usr/local/openca/var/tmp/@__DEVICE__@ openca@ra.openca.org:/usr/local/OpenCA/var/tmp/" "rm /usr/local/openca/var/tmp/@__DEVICE__@"
    EXPORT_IMPORT_DOWN_IMPORT "/usr/bin/scp openca@ra.openca.org:/usr/local/OpenCA/var/tmp/@__DEVICE__@ /usr/local/openca/var/tmp/@__DEVICE__@" "/bin/tar -xvf /usr/local/openca/var/tmp/@__DEVICE__@ -C @__DEST__@" "rm /usr/local/openca/var/tmp/@__DEVICE__@"
    EXPORT_IMPORT_DOWN_TEST ""

9.1.1. Configuration with simple files

The standard data exchange between RA and CA is done via /dev/fd0 (floppy). If the CA and RA are really big then it is recommended to change the data exchange location to a simple file on the local system (for example OPENCADIR/var/tmp/fd0). Please always remember that your apache must be able to access this file. You can also do a chown and set the owner to apache's user.

You also have to edit the dataexchange sections of the .conf files in OPENCADIR/etc/servers/ to point to the new file (edit the lines EXPORT_IMPORT_*_DEVICE).

It is recommended to erase the file after transfers, because the exchange can contain private keys of users.

9.1.2. Configuration via scp

If the CA and RA are located on different machines in a secure environment with perhaps an offline CA it can be difficult to do the dataexchange via simple files (the files have to be transferred between CA and RA, either via a diskette or ftp (not secure)). OpenCA offers the possibility to do the dataexchange automatically via scp.

The RA exports resp. imports from a file located on the system it is installed on (same as local datatransfer). Thus the RA configuration is the same as for the local dataexchange:

  • Create a new file for the export with the correct permissions like OPENCAIDR/var/tmp/fd0

  • Edit the ra_node.conf file in OPENCADIR/etc/servers/ to point to the new file (edit the lines EXPORT_IMPORT_*_DEVICE).

To use scp you must have a working openssh environment with an ssh client on the CA side and an ssh server on the RA side. On the CA side determine the apache home directory by looking at the etc/passwd file (in redhat 8 and 9 this is /var/ww). Do the following:

Now go back to the CA side to edit the files ca.conf and ca_node.conf. The ca_node.conf file already contains a sample scp datexchange section. Comment out the dataexchange section used for local datexchange. Uncomment the scp part and edit it:

  • The EXPORT_IMPORT_DOWN_DEVICE is the file used for datexchange and must have the same name as the one defined in ra_node.conf on the RA side.

  • The EXPORT_IMPORT_DOWN_START can have no value or a value like "ifconfig eth0 up" in which case the CA goes online for the dataexchange.

  • The EXPORT_IMPORT_DOWN_STOP can have no value or a value like "ifconfig eth0 down" in which case the CA goes offline after the dataexchange.

  • In the EXPORT_IMPORT_DOWN_EXPORT line we can define the operations OpenCA has to perform when doing an export (CA to RA transfer).

  • In the EXPORT_IMPORT_DOWN_IMPORT line we can define the operations OpenCA has to perform when doing an import (RA to CA transfer).

  • In the EXPORT_IMPORT_DOWN_TEST line we can define the operations that have to be performed to test the transfer (was it successful or not).

9.2. Adding a new node

If you create a new node e.g. a second RA then you have to support this node with the dataexchange mechanism. Every interface of OpenCA must have a unique module ID. OpenCA manage the complete dataexchange with the ID of the node interface. The node interface knows which object of which datatype was already received by another node.

If you want to create a new node then you must create the corresponding files in OPENCADIR/var/log. You have simply to create some files in the directories OPENCADIR/var/log/enroll and OPENCADIR/var/log/download depending on the direction which you use for epxort. These directories contain some files of the style $number_$datatype. $number is the module ID of the node to which you want to export the data. The datatype is from the exported objects.

If you created a new module ID (e.g. you setup another RA) then you have simply to touch the file $number_$datatype. The new file is empty and so all objects will be exported.