EJBCA CA Concept Guide

Welcome to the EJBCA CA Concept Guide. In here we're going to make a deep dive in to the inner workings of EJBCA without speaking too much about how to perform day to day tasks, which we'll leave to the EJBCA User Guide.

Each page in this Concept Guide links to its corresponding page in the User 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.

Now, this is a daunting task, so we've taken the liberty of splitting the guide up into various sections.

General Concepts

Certificate Authorities

This section 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, 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

Here is where we are starting to get 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. As you may have understood from reading the previous sections 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, which 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. Since certificate profiles have a whole slew of different types of fields, these are described in their own overview page. 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.

End Entities

An end entity is the basic holder and owner of a certificate, whether this be 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 it's desirable for the CA to 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.

Publishers

So we've gotten so far in our process that we've decided what CA's to use and what certificate profiles and end entity profiles to base our certificates on, so what's next? In most cases we want our 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 in order to ensure greater reliability.

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 in order to make sure that your users don't enroll for faulty or weak certificates.

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.

Internal Key Bindings

Internal key bindings is EJBCA's catch-all term for binding non-certificate-signing crypto tokens to specific tasks, specifically OCSP responses and remote authentication.

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.

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.

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.

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 in order 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.