Protocols
The following covers various protocols supported by EJBCA.
Overview
EJBCA can be accessed and managed through other methods than the UI and the CLI, both through homegrown remote protocols and established protocols. The primary purpose for the majority of these is to allow third-party applications to interface with EJBCA as a server.
Proxying
With two instances of EJBCA set up via the EJBCA Peers protocol, the downstream peer will act as a proxy to the upstream one. For example, a CMP message sent to an RA will both be checked upstream with the CA and locally on the RA (and the reply will depend on where the alias is configured). This proxying is disabled by default and can be activated on the Modular Protocols Configuration page.
Protocol Types
The protocols are split into categories below, though some APIs are so wide that they belong in multiple categories.
Certificate Enrollment Protocols
These protocols are generally meant for simple certificate enrollment and renewal operations. All actions mentioned here can also be handled in the Certificate Management Protocols listed below.
Certificate Management Protocols
These protocols are generally more advanced, and besides enrollment also handle operations such as revocation and checking certificate status.
Certificate Status Protocols
Protocol used for verifying the revocation status of certificates:
Protocol used to download CA certificates and CRLs:
Authorization - Client Mode vs RA Mode
Some of the standardized enrollment protocols offer configuration in Client vs RA mode. Client or RA mode is related to authorization of enrollment, something that is commonly not part of the standard itself.
The protocol standard, such as EST, CMP, or SCEP typically define a protocol. This protocol defines what the messages look like, how the messages are transported (in some cases), and what authentication mechanisms are available. Note that the standards typically do not specify how a request is authorized. To exemplify what this means, consider a certificate request coming in from a device claiming to be serialNumber=12345. How does the CA authorize that the sender of this request has the authorization (right) to get a certificate for serialNumber=12345? If a client could get certificates for any serialNumber it requests, this could be used to impersonate other devices (or users of servers in other scenarios).
The authorization has to be designed on top of the standard protocol, and it is here that EJBCA points to Client and RA mode.
RA Mode Authorization Example
In RA mode, EJBCA assumes that the entity sending a request is authorized to issue any certificate allowed by the profiles and access rights of the RA.
An example use case is the PrimeKey Identity Authority Manager (IdAM), a gateway to device enrollment in a factory, which is authorized to issue certificates for any device produced, connecting to the manufacturing execution system that controls which device is being produced at a certain moment. EJBCA can in this case not verify that the device actually being produced has the serial number claimed by the IdAM, but has to trust the IdAM to be installed and configured properly. The IdAM is however only allowed to issue this specific type of device certificates, with limitations be profiles, CAs and access rules on the IdAM itself. For more information, refer to the Identity Authority Manager (IdAM) Documentation.
Client Mode Authorization Example
In Client mode, EJBCA assumes that the entity requesting certificates is an end entity, which could potentially be a malicious actor. EJBCA does not trust this entity to get certificates issued for any serial number, domain name, email address, etc that the entity itself claims. Instead, in Client mode, another administrator entity, who does the identity verification, has to pre-register data (add end entity) in EJBCA. The client making the request can only get a certificate with the pre-registered data. The entity making the request still has to authenticate to EJBCA to prove that it is the pre-registered end entity.
An example is initial enrollment of eNodeBs (base stations in 4G/5G networks) as specified in the 3GPP 33.310 standard. Here a Mobile Network Operator (MNO) buys a set of eNodeBs from a vendor (for example Ericsson). The MNO knows the serial numbers of the eNodeBs purchased and can pre-register these serial numbers. When the eNodeBs are being installed across the country they authenticate using a vendor-issued initial device certificate to the MNOs CA, and retrieve a new certificate from the MNO, with the pre-registered serial number that matches the device's serial number. If a malicious actor would buy an eNodeB from the same vendor and try to connect to the MNO, the malicious actor can not authenticate as any of the pre-registered devices and can thus not get a certificate from the MNO. For more information on the CMP 3GPP standard and EJBCA,s integration, see Using CMP with 3GPP.
For any enrollment use case it is important to consider authorization in the system design, and note that authorization is outside of the protocol standard itself. If not considering the proper level of authorization, the system level of security will be very low, even when using a technically secure protocol.