RA Chaining Architecture for Multi-Tenant Environments

ENTERPRISE

This page provides an overview of the Registration Authority (RA) chaining architecture and the required configuration steps for multi-tenant EJBCA environments using reverse Peer Connections.

Architecture Overview

EJBCA can be configured with reverse Peer Connections to achieve RA chaining. This is useful in cases where multiple Tenant RAs send requests to an EJBCA Cloud Certificate Authority (CA), but the customer does not wish to accept incoming connections to their network and RA.

In a typical RA-to-CA setup, the CA establishes a connection to the RA and polls for requests. As a general rule, there should be no incoming connections to the CA. But when using RA chaining with reverse Peer Connections the Tenant RA is configured with outgoing connections and will send the requests via an RA Proxy (or Cloud RA) that accepts incoming connections from both the CA and the Tenant RA. 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.

RA Chaining for multi-tenant environments is not supported on the Legacy Hardware Appliance.

Set up EJBCA instances for RA Chaining

Perform the following steps to set up EJBCA instances for EJBCA chaining:

Install the CA (see Install EJBCA as a CA with a Management CA)
Install the RA Proxy instance as an RA (see Install EJBCA as an RA or VA)
Install the Tenant RA instance as an RA (see Install EJBCA as an RA or VA)
Configure a Peer Connection between the CA and the RA Proxy (see Connecting an RA to a CA over Peers)
Configure a Remote Authenticator for the Tenant RA (see Setting up a Remote Authenticator)
If you have not configured web.reqcertindb=false in the configuration file web.properties you need to import the Remote Authenticator certificate from the Tenant RA into the RA Proxy. Also, if not already imported, you need to add the issuing CA of the Remote Authenticator certificate to the RA Proxy server truststore.
Example: Import the CA to the RA Proxy truststore:
BASH
```
keytool -import -trustcacerts -file externalca.pem -keystore p12/truststore.jks -storepass changeit -alias externalca
# Redeploy EJBCA truststore using 
ant deploy-keystore 
# and restart the application server to make sure the new truststore is in use
```
Example: Import the Remote Authenticator certificate to the RA Proxy EJBCA database:
BASH
```
bin/ejbca.sh ca importcert --username tenantAuthenticator --password foo123 --caname SomeCA -a ACTIVE -f /tmp/tenantAuthenticator.pem
```
Set up an Outgoing Peer Connection on the Tenant RA:
- In the Admin Web, click Peer Systems.
- In the Outgoing Peer Connection section, click Add.
- Select the new Remote Authenticator and enter the correct URL to the RA Proxy, then click Create.
- Click Ping for the new Outgoing Peer Connection to open the initial connection.
On the RA Proxy, verify that the connection from the Tenant RA is among the incoming connections and create a Role for that tenant:
BASH
```
  /peerincoming/: Allow
  /ra_slave/manage/: Allow
```
Add the Tenant RA Remote Authenticator certificate to the RA Proxy Role on the CA.

Configure EJBCA instances for RA Chaining

The following sections describe configuration settings specific to RA chaining.

Some of these configurations may already have been partially completed during the Set up EJBCA instances for RA Chaining procedure.

CA Configuration

The following configuration is performed on the EJBCA CA instance.

CA Peer Systems - Outgoing Peer Connector

Allow outgoing connections from the CA to the RA Proxy:

Configure to allow for processing incoming requests from the tenant via the RA Proxy:

Modify authorization for requests processing. From the outgoing Peer Connector, click Authorized requests:

CA Roles

A Role must be configured on the CA for the RA Proxy connection.

If using a single Role, the Role must have the RA Proxy as well as the Tenant RA (Remote Authentication certificates) as members, see Step 8.

Separation between tenants, multi tenancy, is achieved by creating separate Roles for each tenant. Each tenant Role will then specify exactly what the tenant will and will not have access to. The RA Proxy Role must then combine the access rules of all tenants. In such a case where separation is desired, it is important to not have the tenants as members of the RA Proxy Role, or there will be no separation between tenants.

RA Proxy Configuration

The following configuration is performed on the EJBCA RA Proxy instance.

RA Proxy Peer Systems - Incoming Connections

The RA Proxy must accept incoming Peer Connections from both the CA and the Tenant RA:

The warning icon displayed over the Tenant to Proxy Role indicates that even though RA requests are accepted in this Role, there are no active CAs on this instance. For an RA Proxy in an RA Chaining setup, this warning can safely be ignored.

RA Proxy Roles

The RA Proxy must accept incoming Peer Connections from both the CA and all Tenant RA. The Role for the Tenant RA must accept requests and the Role for the CA must accept long-hanging connections.

Consideration of any separation between tenants, multi tenancy, is not needed when configuring the Role for the Tenant RAs on the RA Proxy instance. There needs only to be one Role for all Tenant RAs and that Role only serves to allow for forwarding of the requests to the CA. At the CA instance, filtering of Roles is performed to ensure the separation of tenants.

CA to RA Proxy Role:
Tenant RA to RA Proxy Role (see also Step 7):

Tenant RA Configuration

The following configuration is performed on the Tenant RA instance.

Tenant RA Peer Systems, Outgoing Peer Connector

Outgoing connection:
To not process incoming requests, clear the option Process incoming requests:

Tenant RA Roles

No additional Roles specific to RA chaining are required on the Tenant RA instance.

Other Configurations

Administrator roles

Administrators using the Tenant RA still require permissions on the CA instance, as in any standard EJBCA deployment.

Troubleshooting

Duplicate Host Names

Ensure that all EJBCA instances use unique host names.

If multiple instances share the same host name, the RA Proxy may not correctly process peer requests from Tenant RAs.

Browser Cache and CA Access

After configuring Peer Systems and Roles, users may need to clear browser data on the Tenant RA instance before correct CA access is available.

This issue can typically be identified by symptoms such as:

Missing enrollment options in the RA Web