EJBCA Concepts

The following lists definitions for general and EJBCA specific concepts and key terms. EJBCA implements the Certification Authority (CA) part of a Public Key Infrastructure (PKI) according to standards such as X.509 and IETF-PKIX. As such it follows the general PKI concepts closely. The administration of the PKI has some EJBCA specific concepts in order to implement unique flexibility.

General Concepts

Certification Authority (CA)

A Certification Authority (CA) issues certificates to and vouches for the authenticity of entities. The level of trust you can assign to a CA is individual, per CA, and depends on the CAs Policy (CP) and CA Practices Statement (CPS). 

RootCA

A RootCA has a self-signed certificate and is also called Trusted Root. Verification of other certificates in the PKI ends with the RootCAs self-signed certificate. Since the RootCAs certificate is self-signed it must somehow be configured as a trusted root for all clients in the PKI.

SubCA

A subordinate CA, or SubCA for short, is a CA whose certificate is signed by another CA, that can be another SubCA or a RootCA. Since the SubCAs certificate is signed by another CA, it does not have to be configured as a trusted root. It is part of a certificate chain that ends in the RootCA.

Registration Authority (RA)

A Registration Authority (RA) is an administrative function that registers entities in the PKI. The RA is trusted to identify and authenticate entities according to the CAs policy. There can be one or more RAs connected to each CA in the PKI.

Validation Authority (VA)

A Validation Authority (VA) is responsible for providing information on whether a certificate is currently valid or not. The VA does not issue or revoke certificates, but it validates certificates by providing a list of revoked certificates for a CA, known as a Certificate Revocation List (CRL). Another method that the VA can support is the Online Certificate Status Protocol (OCSP). It is a real-time lookup of a certificate status, compared to the CRL which is generated on a set schedule. The VA can respond to OCSP requests and reply if a certificate is good, revoked, or unknown. There can be one or more VAs connected to each CA in the PKI.

End Entity

An End Entity is a user of the PKI, like a device, person or a server. It is called the End Entity because in a hierarchy of certificates in the PKI, it is always the end point, since it is not authorized to issue any certificates of its own.The End Entity individual or device requests a certificate from the CA or RA.

EJBCA Specific Concepts

Certificate Profile

A Certificate Profile is used to configure certain content and constraints of certificates, such as certificate extensions.

The certificate extensions allows you to define if a specific extension is present and whether it is critical or not. Some extensions are populated with a value, where it is the same value for all certificates such as CRLDistributionPoint. For other extensions only the presence is determined, where the value is user- or cert-specific such as SubjectAlternativeName. Here is also determined if these certificates will be published and with which publisher.

End Entity Profile

The End Entity Profile defines what information can be in the certificate, for example, country and organization. The Certificate Profile (as a constraints template) and End Entity Profile (as a certificate content template) and used together to create the certificates signed by the CA.

End Entity Profiles determine what data can or must be present for users connected with the profile. Some values can also be pre-determined such as the organization (o in the Distinguished Name (DN)). The End Entity Profile contains all information, that is specific to each individual End Entity, for issuance of certificates. When adding a user in the PKI, the user must be connected with an End Entity Profile. The End Entity Profile specifies one or more certificate profiles used when generating certificates.

Crypto Token

In EJBCA, cryptographic keys are stored in a Crypto Token. A Crypto Token can either be stored in a database, known as a soft Keystore, or on a Hardware Security Module (HSM).

A Crypto Token is the token used by a CA to store its keys. The Crypto Token's most important key are the CA signature keys. The Crypto Token can also contain other keys used for encryption of sensitive data in the database. A Crypto Token can be configured per CA or multiple CAs can share a Crypto Token.The different forms that are stored in the database are:

  • Soft token PKCS#12 files protected by a password.
  • Hardware token configuration, usually referencing a Hardware Security Module (HSM) accessed using the PKCS#11 API.

Publishers

A publisher stores issued certificates to a central location. EJBCA have implemented support for LDAP and Active Directory but it's also possible to create customized plug-ins.

Internal Key Binding

An Internal Key Binding can be used to make keys in a Crypto Token available for other uses than in a CA. It is a reference to a key pair available to the EJBCA instance, a non-CA certificate, an optional list of trusted certificates and properties for its purpose. It can be thought of as a simplified key store with purpose-specific properties.For example, an OcspKeyBinding can be used to sign OCSP responses on behalf of a CA. It has a key in an HSM accessible from the EJBCA instance (via a Crypto Token) and an OCSP signing certificate. Additionally, the trusted certificates can be used to verify that OCSP requests are sent from a trusted source and additional properties can be used to specify how long an OCSP response should be valid.

Peer Connector

A Peer Connector is a representation of a remote (EJBCA or EJBCA compatible) peer system and can be used for automated management of the remote system. A proprietary protocol is used over a dual authenticated HTTPS channel (where the client certificate keys can be stored in an HSM).Example: If one EJBCA instance (acting as CA) is given sufficient authorization at another EJBCA instance (acting as VA), the first can publish certificate revocation information to the second instance or perform automatic renewal of OCSP signing keys and certificates over the secure channel.

External RA (EJBCA Enterprise)

In some cases, for security reasons, is it preferable to deny all in-bound traffic to the CA and instead let the CA periodically fetch and process information from external trusted data sources. For this reason there is an add-on module provided with the EJBCA Enterprise distribution called 'externalra', which is short for External RA API.

Protocols

Online Certificate Status Protocol (OCSP)

OCSP is used by PKI clients to verify the validity of certificates in real-time. OCSP is defined in RFC 6960 and RFC 5019.

Certificate Management Protocol (CMP)

CMP is an Internet protocol used for obtaining X.509 digital certificates in a public key infrastructure (PKI). It is described in RFC4210 and is one of two protocols to use the Certificate Request Message Format (CRMF), described in RFC4211.

Enrollment over Secure Transport (EST)

EST is a standardized certificate enrollment protocol that describes an X.509 certificate management protocol. EJBCA supports the EST protocol as defined in RFC7030.

Simple Certificate Enrollment Protocol (SCEP)

SCEP is a protocol commonly used by network equipment to enroll for certificates. SCEP has in general use been supplanted by the similar Enrollment over Secure Transport (EST) protocol, which we recommend as an alternative.

Automatic Certificate Management Environment (ACME)

ACME is a protocol that a Certificate Authority (CA) and an applicant can use to automate the process of verification and certificate issuance.