Introduction

EJBCA can be configured to act as Certification Authority (CA), Validation Authority (VA), and Registration Authority (RA) or any combination of the three, distributed across many machines. This requires connections between the instances:

1. The CA needs to be connected to the VA in order to publish certificates - counter to the VA which needs to be connected to the CA in order to automatically update signing certificates.

2. The RA needs to be connected to the CA in order to pass on certificate requests.

On the other hand, common domain security models have the following requirements:

1. All connections must be by mutually authenticated TLS.

2. The CA must be behind a firewall allowing only outgoing connections due to VAs and RAs most often residing in lower security domains in order to be accessible to clients.

While the first requirement is easy to solve, the second one poses some issues with the connections modeled above.

EJBCA Peer Systems

EJBCA solves the second requirement described above using a proprietary protocol named Peers Systems, based on mutually authenticated TLS. It builds on the following principles:

• All TLS connections are initiated on the instance acting as CA. While this is a fairly simple concept for CA → VA publishing as it only involves outgoing traffic, it does pose some issues for certificate requests from the RA and signing certificate renewal requests from the VA, as these are initiated on the downstream node.

• TLS connections are authenticated by a CA known to both nodes, commonly the Management CA. On the upstream node, this connection is represented by an Authentication Key Binding.

• Instead of creating and dropping connections, the CA establishes connection pools on the VA or RA, which is both used for outgoing traffic and for the downstream node to initiate requests. This allows for example an RA, to synchronously pass certificate requests up to the CA, without breaking domain security.

• Internal management operations are not exposed through the API, meaning that even with the complete hostile takeover of a VA or RA, no CA keys can be generated, profiles modified or configurations changed.

• Each EJBCA node is internally agnostic of its role or place in the hierarchy. This means that an instance of EJBCA is not limited to a single role, but can be any combination of the three, or even act as CA for itself and VA for another instance of EJBCA.

• Each Peer Connection has its own role and authorization rules, meaning that of the already limited set of operations in the API, they can be further reduced to a limited scope of CAs or profiles. This both limits the damage of a hostile takeover of an RA node, and allows for multi tenancy (where several organizations share the same CA without knowing of each other) and organizational divisioning.
  

This is established by establishing mutually trusted TLS between the upstream and downstream nodes, and what is required to accomplish this is to set up an Authentication Key Binding on the upstream node, whose keys are signed by a CA trusted by both parties (which in almost all cases would be the Management CA).