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:

OCSP

Protocol used to download CA certificates and CRLs:

Certificate and CRL Access over HTTP

General Protocols

Protocol covering other functions (CA management):

EJBCA Web Services

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.

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.