Certification Authority (CA)

A 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)

An 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 VA is responsible for providing information on whether certificates are valid or not. There can be one or more VAs connected to each CA in the PKI.

End-entity

An end-entity is a user, such as an e-mail client, a web server, a web browser or a VPN-gateway. End-entities are not allowed to issue certificates to other entities, they make up the leaf nodes in the PKI.

Certificate Profile

A certificate profile determines non-user specific content and behavior of certificates. The largest part is extensions and here you decide 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

End Entity Profiles determine what data can or must be present for users connected with this profile. Some values can also be pre-determined such as the organization, o in the dn. It 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

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 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 (Enterprise Edition Only)

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.