Peer Systems

ENTERPRISE

The following provides conceptual information about Peer Systems.

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

EJBCA can be configured to act as a Certificate Authority (CA), Validation Authority (VA), Registration Authority (RA), or any combination of these across multiple machines. This requires connections between the instances:

The CA must connect to the VA to publish certificates.
The VA must connect to the CA to automatically update its signing certificates.
The RA must connect to the CA to pass on certificate requests.

Common domain security models impose the following requirements:

All connections must be by mutually authenticated TLS.
The CA must be behind a firewall allowing only outgoing connections, since VAs and RAs typically operate in lower security domains (in order to be accessible to clients).

While the first requirement is easy to meet, the second creates challenges for the connections described above.

EJBCA Peer Systems

EJBCA solves the second requirement described above using Peer Systems, based on mutually authenticated TLS. It builds on the following principles.

In the following sections, CA, VA, and RA refer to separate EJBCA instances operating in those roles.

All TLS connections are initiated on the instance acting as CA. This is straightforward for CA → VA publishing, since it involves only outgoing traffic, but it can create challenges for certificate requests from the RA and signing certificate renewal requests from the VA, which are initiated on downstream nodes.
TLS connections are authenticated by a CA known to both nodes, typically the Management CA. On the upstream node, this connection is represented by a Remote Authenticator.
Rather than creating and closing connections for each request, the CA maintains connection pools to the VA or RA. These pools support both outgoing traffic and downstream requests. For example, this allows an RA to synchronously pass certificate requests to the CA without breaking domain security.
Internal management operations are not exposed through the API. Even if a VA or RA is compromised, CA keys cannot be generated, and profiles or configuration cannot be modified.
Each EJBCA instance is role-agnostic. A single EJBCA instance can perform any combination of CA, VA, and RA roles, or act as a CA for itself and a VA for another EJBCA instance.
Each Peer Connection has its own role and authorization rules. The limited set of API operations can be further restricted to specific CAs or profiles. This limits the potential impact of a compromised RA and enables multi-tenant deployments, where multiple organizations share the same CA without visibility into each others data, as well as organizational separation.

Trust between upstream and downstream nodes is established via mutually trusted TLS. To set up this trust, a Remote Authenticator on the upstream node is set up with keys signed by a CA trusted by both parties, typically the Management CA.

Reverse Peers and RA Chaining

EJBCA can be configured with Reverse Peers to support RA chaining. This is useful when multiple tenant RAs submit requests to a cloud-based CA, but incoming connections to the tenant PKI are not allowed.

The standard configuration for RA-to-CA communication is for the CA to establish the connection to the RA and then poll for requests. As a general rule, there should be no incoming connections to the CA.

When using RA chaining with Reverse Peers, the tenant RA establishes outgoing connections to an RA Proxy, which accepts incoming connections from both the tenant RA and the CA. The CA polls the RA Proxy for requests from the tenant RA and processes them only if the request matches a role with sufficient permissions.