This guide describes the basic concepts if the EJBCA RA. To read more about how to manage the RA, see the RA Operations page.
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? As I'm sure you know a Registration Authority handles enrollment operations, and in the EJBCA context this takes on a two-fold meaning:
One aspect is the actual interface through which one performs enrollment operations, which is discussed in the first part of this page under the section General Concepts
The other is an RA as a standalone instance of EJBCA, meant to proxy the instance acting as CA over peers. Operations against this instance can be done in the interface described in these sections, but can also be through other enrollment means such as ACME, EST, REST, etc. How this is designed and handled is discussed under the the section System Architectural Concepts and its various subsections. 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.
A basic facet of any RA if for users to be able to directly interface against it in order 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. What is important to know is that certificates are made in a two step process:
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.1
The RA can also be configured to allow for unauthenticated connections (either over plain http, or over https, or both) in order to
1 Will only work for RSA encryption keys, as EC does not allow for encryption.
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.
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.
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
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.
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 which 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.
To read more about this, see the RA Administration Page.
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. See Custom RA Stylesheets page for more information.
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 Security Features in EJBCA RA Concept Guide.
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.