Introduction
This is a brief explanation of all the the concepts in EJBCA like end entity profile, certificate profile and so on and how they relate to one and another.
EJBCA implements the CA part of a 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.
Terminology
| EJBCA | Enterprise Java Beans Certificate Authority |
| PKI | Public Key Infrastructure |
| CA | Certificate Authority |
| RA | Registration Authority |
| VA | Validation Authority |
| DN | Distinguished Name |
| HSM | Hardware Security Module |
| CRL | Certificate Revocation List |
| OCSP | Online Certificate Status Protocol, RFC2560 |
| CMP | Certificate Management Protocol, RFC4210 |
| SCEP | Simple Certificate Enrollment Protocol |
General concepts
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.
EJBCA specific concepts
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.
CA Token
A CA Token is the token used by a CA to store it's keys. The CA Token's most important key are the CA signature keys. The token can also contain other keys used for encryption of sensitive data in the database.
CA Tokens are configured per CA and can be in different forms:
- Soft tokens, PKCS#12 files protected by a password.
- Hardware tokens, usually 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.
External RA
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 distribution called 'externalra', which is short for External RA API.