ENTERPRISE  This is an EJBCA Enterprise feature.

The following provides conceptual information about Peer Systems.

For more information about how to work with Peer Systems, see Peer Systems Operations.

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:

In the following, the terms CA, VA or RA refer to separate EJBCA instances acting in those specific roles.

  • 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 a Remote Authenticator.
  • 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 a Remote Authenticator 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).

It is possible to configure EJBCA with Reverse Peers to achieve RA chaining. This solution is useful in cases where multiple Tenant RAs send requests to an EJBCA Cloud CA, but the customer does not want to accept incoming connections to their PKI.

The typical way to configure Registration Authority (RA) to Certificate Authority (CA) communication is to let the CA establish the connection to the RA and then poll for requests. As a general rule, there should be no incoming connections to the CA. But when using RA chaining with reverse per connections, the tenant RA is configured with outgoing connections and will send the requests via an RA Proxy that accepts incoming connections from both the tenant RA and the CA. The CA will poll the RA Proxy for requests from the tenant RA and handle the requests if there is a matching role with sufficient permissions.

Related Content