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 ""
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.
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).
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.