EJBCA CA Concept Guide

This EJBCA CA Concept Guide takes a deep dive into the inner workings of EJBCA without detailing how to perform day to day tasks, which is covered in the EJBCA Operations Guide.

Each page in this Concept Guide links to its corresponding page in the Operations Guide, so if you've found something you'd like to try out, then feel free to click down further. Here we'll also link various components within EJBCA to more general PKI concepts.

General Concepts

Certificate Authorities

The Certificate Authority Overview generally covers what a CA means in an EJBCA context, going into detail in regards to the various CA Fields, and describing a CA's relation to Publishers Overview, Validators Overview and Crypto Tokens, as well as Approvals to add a degree distributed access control for operations such as activating CAs or renewing CA certificates. This guide has a further subsection describing managing CVC CAs.

Crypto Tokens

The Crypto Tokens Overview gets down to the mechanics of what works under the hood. A crypto token represents a set of keypairs, located either in the database (as PKCS#12) or on an HSM (as PKCS#11) which the CA uses for various signing and encryption operations, but which are also used for other signing operations such as by OCSP Responders and for remote authentication to other EJBCA instances.

Certificate Profiles

Certificate Profiles provide a template and constraints for the certificates produced for a certain purpose. The certificate profile chosen for a CA constrains the certificates for that CA's keys and not the certificates which are in turn signed by those keys. These are instead defined in the End Entity described in the next section.

A Certificate Profile defines details such as purpose, available key algorithms, key sizes and extensions for restricting function. Certificate profiles have countless types of fields, described in their own overview page, see Certificate Profile Fields. Additionally, EJBCA provides the ability to define custom certificate extensions and extended key usages. Certificate Profiles also have their own set of configurable Approval constraints to distribute access control for operations such as enrolling and renewing certificates. For more information, see the Certificate Profiles Overview.

End Entities

An end entity is the basic holder and owner of a certificate, whether this is an actual person, a device, a subCA or a component like an OCSP responder. An end entity is always owned by a Certificate Authority, and the certificates issued to it are defined by a single Certificate Profile. In order for administrators to limit the enrollment options for users (predefining, forbidding or requiring certain fields), each end entity also conforms to an End Entity Profile. Multiple end entities can share the same profile, so it can be set to be available for multiple CAs and multiple certificate profiles.

The End Entity Profile Fields are defined in their own page, and besides the constraints mentioned previously the values can also be restricted via regular expressions. There are some use cases where the CA should produce the key pairs on the user's behalf (instead of just signing a CSR), and in those, the key pair can be saved (encrypted in PKCS#12) in the database, allowing later key recovery. For more information on End Entities, see the End Entities Overview.

Publishers

So you've decided what CA's to use and what certificate profiles and end entity profiles to base your certificates on, so what's next? In most cases you want your certificates to end up somewhere useful other than just in the hands of the end user. For that reason, we use the concept of Publishers, which handle tasks such as publishing certificates to a VA to handle OCSP replies, to an LDAP, Active Directory, or any number of other implementations. Publishing can either be done directly or asynchronously through a queue to ensure greater reliability. For more information, see the Publishers Overview.

Validators

As a CA you may wish to retain some control over what certificates you issue, what for keys sign, to be able to run external certificate linters and other things. EJBCA provides a powerful suite of Validators that are run during the issuance process to make sure that your users don't enroll for faulty or weak certificates. See Validators Overview.

Services

Some tasks need to be done in the background, such as publishing certificates through a queue, renewing signing certificates or producing CRLs. Our library of service workers perform these tasks at configured intervals and offer a powerful API for writing your own services.

Approvals and Approval Profiles

While just issuing certificates is all well and good, a proper CA needs to provide multi-user accountability and access control to issuance operations. While the standard Accumulative Approval Profile provides a simple n-number of approving administrators requirement, Partitioned Approval Profiles allow for a complex approvals flow of sequences and parallel partitions. To read more about approvals, see Approvals and Approval Profiles.

Remote Authentication

Remote authentication binds non-certificate-signing crypto tokens to specific tasks, specifically OCSP responses and remote authenticators. See Remote Authenticators Overview.

Peer Systems

EJBCA provides a powerful framework for connecting instances of EJBCA together over TLS, allowing a CA to delegate VA and RA tasks to nodes placed in the DMZ. See Peer Systems.

Logging in EJBCA

EJBCA logs output through three methods:

• The System Log, which by default outputs most significant actions and server state changes. It can be configured to output debug information as well in order to assist with troubleshooting issues.
• The Audit Log which logs all actions related to issuance or CA state changes, as well as security-related actions. The audit log can be made tamper-proof using the integrity protected log device.
• The OCSP Transaction log, that specifically logs OCSP requests to a separate file.

For more information, see Logging.

Remote Protocols Overview

EJBCA supports a wide array of protocols for various use cases and needs. The far most common is OCSP for handling certificate status requests. We also support strict enrollment protocols such as SCEP, EST and ACME, and more advanced certificate management protocols such as CMP, our own Certificate Management REST API, and EJBCA Web Services. The last also provides a wide array of other tasks, such as approvals and CA management. All protocols can be proxied through another instance of EJBCA acting as RA connected over peers. For more information, see Protocols.

Rights Management

Roles and Rights

With any enterprise scale PKI operation, a complex system for managing roles and rights is required. EJBCA provides an extensive architecture of roles and access rules to allow fine-grained access control of CAs, crypto tokens and profiles, with separate view-only modes for use by auditors. This access control extends to the approvals framework (allowing specific roles to approve certain approval conditions) and to RAs connected over peers to allow for different RA users to interface with the same CA oblivious of each other and minimizing the risks of an RA becoming compromised. For more information, see Roles and Access Rules.

Uncommon Features

The following features are only used infrequently by very specific use cases.

User Data Sources

The basic User Data Sources framework allows importing user data from existing databases and enables importing user data from an LDAP and AD. See User Data Sources.