The usage of Public-key Cryptography relies on the usage of digital certificates, to authenticate relying parties. However, given the complex nature of the issuance and management of the digital certificates lifecycle, organizations that want to carry out those types of operations usually need to use Certification authority applications.
\r\nThe TOE is a Certification authority (CA). As PKI Certification authority, EJBCA issues and manages the life cycle of public key certificates of the type specified in the X.509 v3, C-ITS Enrollment CA IEEE 1609.2, and CVC BSI TR-03110, standards, allowing the issuance of public key certificates for different purposes, such as:
\r\nAdditionally, the TOE also can act as a CA independent OCSP responder service.
\r\nTechnology wise, given that it is composed of a set of Jakarta EE modules, EJBCA is platform independent.
\r\nRegarding its usage, EJBCA is deployed as a regular JEE application, making most of its functionalities available through a set of Web interfaces.
\r\nCreation of electronic signatures is a vital part of PKI applications. Electronic signatures can be created in several ways, low level and high level. The TOE will provide means to obtain a private key reference that can be used by relying applications for signing of specific document types. Signatures can be created in cryptographic modules, either using software or hardware (such as HSMs and smart cards).
\r\nPKI management systems need to be able to create, process, and manage certificates throughout their lifecycle, including certificate revocation. Revocation information can be distributed and consumed through multiple mechanisms. The TOE supports certificate revocation using standards-based approaches, including generating and processing Certificate Revocation Lists (CRLs), as well as parsing OCSP requests and generating OCSP responses to provide near real-time certificate status information.
\r\nThe functions for data integrity protection are used to ensure that data, in transit or in storage, cannot be tampered without detection. Integrity protection can be ensured using several techniques, where the most common are message authentication codes and digital signatures.
\r\nOne very common requirement on sensitive systems is to provide secure audit records. Though creating audit records is simple, ensuring that they are not tampered with is much more difficult. By using the security audit functions of the TOE, an application will be able to create audit trails that meet ETSI EN 319 401 and ETSI EN 319 411 requirements for secure audit.
\r\nAuthentication and authorization are the most basic security functions needed for an application to provide services to TOE users.
\r\nAuthentication is the process of identifying the TOE users. Authentication can be performed in many ways, and the TOE provides a framework that can be extended by relying applications in order to meet their specific authentication needs.
\r\nAuthorization approves or rejects a request for accessing a specific resource. In order to control authorization, the TOE also keeps a database of access rules. The access rules are connected to the authorization system so that TOE user's access to resources can be controlled. Some access rules are already built-in in the TOE, but they can be changed by the relying application.
\r\nAdditionally, access control is also enforced through role separation, based on a combination of access rules.
\r\nThe private keys used by the TOE to perform cryptographic operations are kept inside tokens, which can be activated/deactivated to allow/prevent using the keys they hold.
\r\nThe TOE can generate key pairs for its own usage, kept inside a cryptographic module.
\r\nThe various security functions of the TOE manage different types of data, including configuration data and recoverable key pairs. Disaster recovery procedures require that it must be possible to restore a security system in a determined state recovered from existing backups. Therefore, the backup functions of the TOE make it possible not only to perform secure backup operations, but also to restore the contents of those backups at another installation. The security functions of the backup make it possible to ensure that the backup, and thus the restored system, cannot be compromised and that confidential data is not revealed.
\r\nEJBCA allows the configuration of several CAs in the same TOE instance.
\r\nSince the contents of the X.509 certificates and CRLs can be extended to include additional relevant information, the TOE supports the configuration of profiles that define the fields and default values that should be included in the issued certificates and CRLs. For each existing CA, it is possible to configure one CRL profile and one or more certificate profiles.
\r\nIssued digital certificates are associated to users, created during the enrollment process. In addition to downloading their certificate(s), authenticated users can regain access to their key pairs kept by the TOE for key recovery purposes (after approval by a TOE user).
\r\nAdditionally, certain users can be assigned one or more roles that grant them access to specific features of the TOE, like certificate suspension/revocation/activation, key recovery approval, configuration, administration, or user management.
\r\nTo make them widely available to external users and applications, the TOE supports the configuration of domain-specific publishers that are responsible to relay issued digital certificates and CRLs to third-party repositories where they can be accessed or used.
\r\nBesides being able to publish them in the relevant repositories, the TOE also allows the lookup and retrieval of specific certificates and CRLs.
\r\nAs illustrated by the following figure, the TOE includes:
\r\nExcluded from the TOE is:
\r\nFigure 1 TOE Boundary
\r\nAs illustrated in Figure 1, the TOE establishes the following communications:
\r\nExcluded from the TOE scope:
\r\nThe evaluated configuration, as defined in the Security Target, is the EJBCA Enterprise 9.3.3 software installed upon a general-purpose server platform. The following table list all the components in the evaluated configuration.
\r\n| \r\n Part \r\n | \r\n\r\n Description \r\n | \r\n
| \r\n Abstract Machine \r\n | \r\n\r\n Dell EMC PowerEdge R440 with Xeon Silver 4216 \r\n | \r\n
| \r\n Abstract Machine Operating System \r\n | \r\n\r\n Red Hat Enterprise Linux 9.4 (kernel: 5.14.0-427.13.1.el9_4) \r\nRHEL Kernel CPU Time Jitter RNG Entropy Source version 2.2.0 (ESV E#54) \r\n | \r\n
| \r\n Container \r\n | \r\n\r\n Docker version 27.1.2 \r\n | \r\n
| \r\n Container Operating System \r\n | \r\n\r\n Alma Linux 9.6 \r\n | \r\n
| \r\n JEE 10 compliant application server \r\n | \r\n\r\n WildFly 35.0.1 \r\n | \r\n
| \r\n Java Virtual Machine (JVM) \r\n | \r\n\r\n Oracle OpenJDK 17.0.16 \r\n | \r\n
| \r\n Relational Database \r\n | \r\n\r\n MariaDB 11.5.2 \r\n | \r\n
| \r\n HSM \r\n | \r\n\r\n Thales DPoD Luna 7 FIPS 140-2 validated (CMVP #4327 and ESV E#98) \r\n | \r\n
To use the product in the evaluated configuration, the product must be configured as specified in the EJBCA Enterprise 9.3.3 Common Criteria Guidance Supplement v1.1.
\r\nThe TOE supports several features that are not part of the evaluated functionality. These features are not tested and excluded from the scope of the evaluation: the TOE shall be deployed in a general computing platform. Deployment models that include hosting on, or delivering service from cloud environments are excluded from the evaluated configurations.
\r\nThe evaluation was carried out in accordance with the Common Criteria Evaluation and Validation Scheme (CCEVS) processes and procedures. EJBCA Enterprise 9.3.3 was evaluated against the criteria contained in the Common Criteria for Information Technology Security Evaluation, Version 3.1 Revision 5. The evaluation methodology used by the evaluation team to conduct the evaluation is the Common Methodology for Information Technology Security Evaluation, Version 3.1 Revision 5.
\r\nThe product, when installed and configured per the instructions provided in the preparative guidance, satisfies all of the security functional requirements stated in the Security Target for EJBCA Enterprise 9.3.3 v1.4. The evaluation underwent CCEVS Validator review. The evaluation was completed in January 2026. Results of the evaluation can be found in the Common Criteria Evaluation and Validation Scheme Validation Report, CCEVS-VR-VID11530-2026 prepared by CCEVS.
","environmental_strengths":"One very common requirement on sensitive systems is to provide secure audit records. Though creating audit records is simple, ensuring that they are not tampered with is much more difficult. By using the security audit functions of the TOE, an application will be able to create audit trails that meet ETSI EN 319 401 and ETSI EN 319 411 requirements for secure audit.
\r\nThe TOE generates the audit records listed in Table 12, Table 13 and Table 14 of the ST. The event formatting is described in the guidance documentation. The TOE can associate each auditable event with the identity of the user that caused the event. It provides the ability to apply searches of audit data based on serial numbers associated with the event. The TOE provides an 'Auditors' group and stipulates that an auditor can view the signed audit logs.
\r\nThe TOE provides secure storage of audit events and further provides separate audit storage for certificate-related events. The TOE provides no administrator or auditor method for deletion or removal of events, and the TOE generates an error message in the event of an error that prevents the TOE from creating new audit records.
\r\nThe certificates and CRLs repository is provided by the database in the operational environment. PKCS#11 is used as interface. Audit events are stored on the TOE platform.
\r\nThe TOE provides certificate-based proof of origin for the certificates it issues by digitally signing each certificate in accordance with RFC 5280. In addition, the TOE provides proof of origin for the certificate status information it issues by digitally signing CRLs (RFC 5280) and OCSP responses (RFC 6960). The TOE uses the HSM to perform the digital signature operations for certificates, CRLs, and OCSP responses using the signature algorithm configured for the issuing CA key (e.g., RSA or ECDSA with the corresponding hash).
\r\nThe TOE relies upon the HSM in the operational environment for cryptographic operations involving persistent private keys, such as key-pair generation, certificate signing, OCSP responses, and protocol response messages (e.g., EST), performed through the PKCS#11 API using calls like C_GenerateKeyPair and C_Sign.
\r\nSecure communications are managed by the TOE’s WildFly application server, which establishes HTTPS/TLS channels by integrating the Bouncy Castle cryptographic module as its JSSE provider. This architecture employs a hybrid cryptographic model to optimize both performance and security.
\r\nThe TOE provides certificate profile functionality and certificate generation services conforming to IETF RFC 5280. A CA account can have one or more profiles which are configured by an administrator using the TOE’s web interface. Using that interface the administrator can assign a name (Certificate Profile ID), extensions, and default properties to the profile.
\r\nThe TOE supports the approval of certificates issued according to a configured certificate profile through the web interface, the RA management interface or EST. Only user roles given ‘Approve End Entity Actions’ permission can approve certificates via the web interface (which is the only interface through which manual issuance occurs).
\r\nThe TOE provides certificate status information through CRLs and OCSP responses. The TOE clears sensitive data from buffers before releasing the buffers.
\r\nThe TOE does not store any personally identifiable information, that does not also appear in a certificate. The TOE handles the TLS session objects.
\r\nThe TSF, in conjunction with the HSM, ensures that sensitive data is securely protected or erased when it is no longer needed, so that any previous content cannot be recovered. This applies to secret and ephemeral keys.
\r\nThe TOE supports Enrollment over Secure Transport (EST) protocol as described in RFC 7030 to receive and act upon certificate enrollment requests using the simple enrollment method described in RFC 7030 Section 4.2.
\r\nCertificate enrollment requests are authenticated using an existing certificate and corresponding private key as specified by RFC 7030 Section 3.3.2.
\r\nThe TOE provides a certificate-based mechanism via web interface. For certificate authentication the TOE uses the HSM to validate certificates. The TOE uses X.509v3 certificates, as defined by RFC 5280, to authenticate privileged users, subscribers, RAs, and DBAccess clients over HTTPS. Certificates can also be used for EST access authentication.
\r\nWhen the TSF cannot determine the current revocation status of a certificate the administrator is allowed to choose whether to accept the certificate or not.
\r\nThe TSF allows the following actions prior to requiring a non-TOE entity to initiate the identification and authentication process
\r\nThe TOE provides all the interfaces necessary to manage the security functions identified throughout this Security Target as well as other functions commonly found in certificate authorities.
\r\nAdministrative roles are fully configurable. The TOE provides default role templates corresponding to the roles defined in the Protection Profile. The corresponding TOE role names are:
\r\nThe TOE protects itself after a secure component failure that will result in an error message giving the Administrator possibility to perform a secure restart. The TOE utilizes a HSM and relies upon the HSM to secure and protect the keys stored by the TOE in the HSM, and to offer services to allow operations using the HSM protected certificates.
\r\nThe TOE obtains the current time from its operational environment.
\r\nThe TOE allows remote users to terminate their interactive session. The TOE also has the capability to display an advisory message (banner) when users access the TOE for use.
\r\nThe TOE protects interactive communication with administrators on the HTTPS (WebUI) interface and both integrity and disclosure protection are ensured. If the negotiation of an encrypted session fails or if the user does not have authorization for remote administration, the attempted connection will not be established.
\r\n","features":[{"id":128,"feature_name":"Asymmetric Key Generation"},{"id":123,"feature_name":"Auditing"},{"id":127,"feature_name":"Certificate Authentication"},{"id":126,"feature_name":"Certificate Validation"},{"id":11,"feature_name":"Certification Authority"},{"id":132,"feature_name":"Cryptographic Hashing"},{"id":131,"feature_name":"Cryptographic Key Establishment"},{"id":129,"feature_name":"Cryptographic Signature Generation"},{"id":130,"feature_name":"Cryptographic Signature Verification"},{"id":146,"feature_name":"DRBG"},{"id":125,"feature_name":"HTTPS Server"},{"id":124,"feature_name":"Key Destruction"},{"id":134,"feature_name":"Keyed-hash message authentication"}]}