RA Chaining

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 CA, but the customer does not wish to accept incoming connections to their network and RA.

RA to CA communication is typically configured by letting the CA establish a connection to the RA and then polling 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.

Set up EJBCA instances for RA Chaining

The following lists steps for setting up EJBCA instances for EJBCA chaining:

Install the CA (see Installing EJBCA as a CA with a Management CA)
Install the RA Proxy instance as an RA (see Installing EJBCA as an RA or a VA)
Install the Tenant RA instance as an RA (see Installing EJBCA as an RA or a 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.

Import the CA to the RA Proxy truststore example:
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
```
Import the Remote Authenticator certificate to the RA Proxy EJBCA database example:
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:
- 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 outlines the RA Chaining specific configurations and they might include altering some previous settings and configurations that are required for this setup.

The steps described in Set up EJBCA instances for RA Chaining may have partially completed some of the following configurations

CA Configuration

The following configurations are executed 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

There must be a Role 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 above.

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 configurations are executed 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

There must be Roles for 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 above):

Tenant RA Configuration

The following configurations are executed on the EJBCA Tenant RA instance.

Tenant RA Peer Systems, Outgoing Peer Connector

Outgoing connection:

Configure not to process incoming request (checkbox):

Tenant RA Roles

No Role specifically related to RA Chaining needs to be configured on the Tenant RA.

Other Configurations

Administrator role

Even though the above configurations relate specifically to RA Chaining with Reverse Peers, an administrator interacting with a Tenant RA still needs permissions on the CA as in any common EJBCA setup.

Troubleshooting

Make sure that all EJBCA instances have a unique hostname, otherwise the RA proxy cannot process the peer requests from the tenant RA.

Browser data and CA access

In some cases, after all Peer Systems and Roles have been configured, it might be necessary to clear the browser data at the Tenant RA for it to get the correct access on the CA instance.

If this issue arises, it can be recognized by e.g. the missing enroll options from the RA Web of Tenant RA. It will also not be possible to use any search functions from the RA Web.