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.

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.