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.
Understanding OpenCA Nodes and Data Exchange
It is important to understand the OpenCA concept of nodes and data exchange in order to build a large, secure, distributed, enterprise class PKI. A lack of such understanding has led to unnecessary complexity in our previous PKI environments. The goal of this document is to help our PKI engineers build an efficient, safe and simple environment through a firm understanding of OpenCA data exchange principles.
OpenCA uses a distributed database model. Each server is a separate database. Each server can have one or more interfaces. An example of an interface is a CA, RA or Public web application. Each of these interfaces reads and writes data from and to its local database. It is possible for a physical server to have multiple databases and multiple instances of the same interface, e.g., a server could have two RAs using completely different directory structures and databases. However, that complexity is beyond the scope of this document. For our purposes, we will assume that a server has a single database.
The odd characteristic of the OpenCA distributed database is that it is not syncrhonized. Each database is completely isolated. That does make sense from the security perspective of a PKI. For example, in an environment where the CAs are normally powered off and isolated from the network, we could not easily maintain a synchronized database architecture.
Data which needs to be shared between servers therefore must be manually synchronized. This is the function of the node interface. The node interface extracts data from the local database and places it in a file, typically a tar file. This file can then be given to a different node on another server which extracts the data from the file and imports it into its local database.
Let's illustrate with the example of a CSR (Certificate Signing Request) in an environment where the CA and RA are on different servers (and thus different local databases). The RA receives the CSR, edits, approves and signs it and then stores it in its local database. The signed CSR somehow needs to get from the local database on the RA to the local database on the CA. The RA node extracts the signed CSRs from the database and writes them to a file. This is the “upload” process although the term upload might be slightly misleading. It does not upload the information to the CA. It merely extracts the data from the database and writes it to a file.
The file created by the RA node must then somehow be transported to the CA. This could be via floppy, zip drive, network or some other method. When the file has arrived at the CA, the CA node can now import the data into the local CA database. This is the “receive” process. The CA can now process the data in the database and sign the certificate based upon the CSR and store that signed certificate in its local database.
The reverse procedure is used to send the certificate back to the RA. The CA node extracts the signed certificate from the database and writes it to a file. This is the “enroll” process. The file is transported to the RA server where the RA node extracts the data from the file and imports it into the RA local database. This is the “download” process.
When all interfaces reside on the same server and use the same database, no nodes are necessary. Nodes are only used to transfer data from one isolated database to another isolated database. Let's illustrate this with the same CSR example but in a single server environment. The RA approves and signs the CSR and saves it to its local database. Since the CA is using the same database, there is no need for data exchange. When the CA looks into its local database to see what CSRs are queued, it will see the signed CSRs already in the database because the RA placed them there.
Conversely, when the CA issues a signed certificate, it stores it in the database. When the RA or Public interface needs to know which signed certificates have been created, it merely looks in its local database because the CA has already put the information there. Again, there is no need for data exchange between separate databases and thus no need for any node interfaces. There is no need to create both an offline and online node when both CA and RA are on the same server. We were formerly held this misunderstanding and unnecessarily complicated our environment.
With this background, we can now create a data exchange methodology which meets our design criteria. There is no magic to the data exchange process. The process is simply this:
Data is extracted by the first node from a local database and written to file.
The file is transported to a second node servicing a different local database.
The second node extracts the data from the file and places it in its local database.
We have two important and somewhat conflicting design criteria. Security is of paramount importance. For example, we would prefer that the CAs not be network accessible. This would imply that data exchange be via floppy or zip disk where the CA Operator receives the portable media from the RA Operator, boots the CA, receives and enrolls from and to the portable media and then powers down.
However, this conflicts with our second very important design criteria of remote access and distributed work. The CAs and RAs may reside in hardened data centers or GNOCs. The RA and CA Operators might be anywhere in the world. Therefore, data exchange via portable media is nearly impossible. There will likely be no one available to insert and remove the media.
This makes data exchange via scp as outlined in the OpenCA documentation a very attractive option. The RA Operators can upload data as often as the wish. The data keeps spooling to the node data tar file and stays in a secure directory on the RA server until the CA Operator requests it. When the CA Operator wishes to work on pending requests or enroll certificates and CRLs, their enroll and receive procedures copy the RA node's tar file via scp and then extract and import the data into the CA local database.
The remote model can be accommodated in any of several ways:
Only https traffic from CA Operators identified by IP address is allowed to the CA.
CA Operators must establish an IPSec tunnel via X.509 certificates. The CA only allows https traffic from a trusted tunnel.
The CAs have no network access but exist on Xen virtual machines. CA Operators connect to the Xen host and run a browser through an X portal to the CA VM. The enroll and receive functions can be written to only activate the network interface when scp data exchange is needed and disable them as soon as the data exchange is accomplished.
CAs on Xen using scp data exchange mean the CA can be powered down except when in use. RA nodes continually export information to their local file stores as the RA Operators edit and approve requests. When the CA Operators are ready to process those requests, they connect to the Xen host and start the needed CA VM (Virtual Machine).
There are several security and procedural issues to discuss. For example, is it more secure to not have the CA on the network but allow CA Operators to have access to the Xen host console which may host other services? We can probably address this through sudo and user accounts for the Operators. However, in a multi-operator environment, would we really want Operators starting and stopping the VMs? What if one Operator is still working when another decides to shut down?
How do we handle the lack of network connectivity for the Operator? The data exchange can be automated to activate an interface and iptables rules just for data exchange and then tear it down. However how will the Operator access the process? If they access the web interface from the browser on their desktop, we must allow network access the entire time the Operator is working. We could have them connect to the Xen host and then run an X session that speaks to the VM. This could not be VNC if there is not network capability but there are alternatives. The browser could then be run on the VM with no network connectivity to the VM except the dynamically created connectivity during data exchange. Is this really more secure? We would, in effect need a large terminal server on the Xen host. It might be a much less aesthetically pleasing experience that a direct browser connection.
If the CAs are network accessible but heavily firewalled, there are limited points of interaction with an intruder. However, if they are only accessed through the Xen console and an intruder compromises the Xen console, they have full console access to the CA.