EJBCA RA Concept Guide

This RA Concept guide describes the basic concepts of the EJBCA Registration Authority (RA).

For information on how to manage the RA, see RA Operations Guide.

For information on the legacy asynchronous External RA implementation, see External RA using Database Polling.

What is the EJBCA RA?

What is there in a name, and what does it mean to have an RA installed? A Registration Authority (RA) handles enrollment operations, which can either be directly through EJBCA's RA interface as described in the following sections, but can also be through other enrollment means such as ACME, EST, REST, etc.

How this is designed and handled is discussed in the section .EJBCA RA Concept Guide v7.5.0#System Architectural Concepts.

The RA can either reside on the same EJBCA instance as the CA, but is more commonly proxied out to its own EJBCA instance and connected to EJBCA through the peers protocol. The purpose of doing so is to not expose the CA to the general domain, but instead keep it in an high-security zone behind a firewall allowing only outgoing connections over TLS, while the RA sits in a low-security zone (i.e a DMZ) which allows incoming connections from either within the network or even wider, depending on use case. Doing so also allows for multiple RAs to be connected to the CA behind a load balancer.

General Concepts

Enrollment

A basic facet of any RA is for users to be able to directly interface against it to enroll for certificates or key stores. The EJBCA provides for two basic workflows, which is either for users to enroll while providing their own identifying information (in the form of username/password) or to enroll for a pre-created end entity and simply submit the username/password which they have been provided. Certificates are made in a two-step process:

  1. First, an end entity is created, defining all values inherent to that end entity such as certificate type (i.e. End Entity Profiles Overview), certificate sub-type (i.e. certificate profile), subject DN values, subject alternative names, etc.

  2. In the second step the actual enrollment occurs, and the certificate/key store is generated. In between these two, there may a series of approvals and validations occurring if the CA is configured for it.

If the RA user is enrolling their own end entity, they'll be given the choice of either entering the complete information (signing algorithm, key size, etc) of the key store they're requesting, or be directed to a field where they can paste/upload a CSR. If the CA is set to allow all enrollment they'll then be allowed to download the key store/certificate in any of the approved formats, otherwise they'll be given an enrollment code which they can use to retrieve the certificate/key store when they have been notified that it's been issued. In the case of a key store, the key store file itself will be locked with the password supplied. EJBCA does not save generated key stores by default, unless the CA has been configured to allow for later retrieval, which will have the CA save the keystore in the database, encrypted by the CA's encryption key. (This only works for RSA encryption keys, as EC does not allow for encryption).

The RA can also be configured to allow for unauthenticated connections (either over plain http, or over https, or both).

Certificate and End Entity Life Cycle Management

The second basic aspect of the RA that most users will interface with is the search screens, which allow for searching for end entities and certificates using partial search data, restricted to whatever the user is allowed to view (see more on that below). Through this view users and admins can request revocations of their certificates.

Approvals Management

An essential part of the workflow for an RA administrator is handling enrollment requests on CAs which have been configured to use approvals. In the EJBCA RA authorized users can log in and handle enrollment requests which require their attention. On an EJBCA instance set up to proxy a CA requests will be seamlessly fed from the CA to the RA, and can be managed from there.

Roles Management

While most role and access rules assignments are handled from the CA UI, the RA provides some limited role administration functionality for authorized users to be able to create additional RA administrators. The purpose of this is to allow Managed PKI configurations (where the RA is fully owned and administrated by a party other than the CA) to manage and administrate their own users. RA administrators created through this interface will be strictly limited to only being able to manage end entities and approving requests - they can get neither administration privileges to the CA nor any management access to the RA itself.

System Architectural Concepts

Transfer Security

When using the EJBCA RA interface connected to another instance configured as CA, the two are connected using the EJBCA Peers Protocol. The basis of Peers is on peer-to-peer communication between to instances of EJBCA over TLS, where the initiating (i.e. outgoing) side identifies itself using a certificate issued by a commonly trusted CA to the receiving (i.e incoming) side, which on the outgoing end will be defined by an Authentication Key Binding. The assumed security level is that the firewall between the two zones will only allow secure outgoing communication from the CA to RA, so thus the CA will initiate communications by leaving a number of long-hanging communication threads to the RA, which it can use to forward requests from the end user. The thread pool is limited, mitigating the risk of a compromised RA being able to perform DOS attacks against the CA.

Domain Security

As mentioned above, complete compromise of the RA (including administrator key pairs) can only lead to limited effects on the CA. While they could at worst enroll certificates and approve requests, the RA communicates to the CA layer (even when the two are on the same instance) through a proxied interface that limits the available operations. If the RA is on a proxied instance (which has a far higher risk of getting compromised being in a lower security zone than the CA), damage is further mitigated through the fact that the peer connection itself is given its own role and associate access rules, meaning that even if an attacker gets ahold of a super admin key pair and uses it on the RA, the scope of the attack is limited to the above; they can still perform no CA management operations nor get access to other CA's hosted on the CA instance that the peer connection isn't authorized to. Further, error messages are filtered when outgoing to the RA, giving a potential attacker little access to unauthorized information. For more information, see RA Administration.

Customizability

The EJBCA RA can be widely customized to fit individual needs, even allowing for various stylesheets to be administrated from the CA, and set differently depending on the role of the user.

For more information, see Customizing the RA Appearance.

Clustering

You can use multiple RA servers to provide higher availability or increase performance. The RA itself is stateless and therefore any user can access any RA server to perform their tasks, as long as it is an RA with the same privileges.

For more information, see High Availability and Clustering.

A user session against the RA UI uses HTTPS sessions, and are typically pinned to a certain node by a load balancer. An RA node must always service one CA cluster, but it does not matter which particular node in the CA cluster that serves a request as long as they all have a common view of the CA database.