CertAgent/Dhuma, the TOE, is an X.509-compliant certificate authority (CA). It is an easily managed, web-based certificate authority (CA) intended to be used as the core component of an enterprise public key infrastructure (PKI). Designed to meet the needs of a wide variety of organizations, the current release offers enhanced enrollment services (EST), remote administration, integrated certificate and certificate revocation list (CRL) database, and an optional independent OCSP responder called Dhuma. It supports an unlimited number of root and intermediate CAs, providing support for as complex a certificate hierarchy as the size of the enterprise warrants. The following diagrams shows the TOE boundary and major components.
\r\nAs Figure 1 shows, CertAgent/Dhuma combined with Apache Tomcat form the Target of Evaluation (TOE). There are 4 high level interfaces that are external to the TOE. The data that traverses these interfaces is protected as shown in the following table.
\r\n| \r\n Interface \r\n | \r\n\r\n Protection \r\n | \r\n
| \r\n Web \r\n | \r\n\r\n HTTP, HTTPS/TLS \r\n | \r\n
| \r\n Database \r\n | \r\n\r\n Operating system \r\n | \r\n
| \r\n OCSP \r\n | \r\n\r\n HTTP, HTTPS/TLS \r\n | \r\n
| \r\n PKCS#11 \r\n | \r\n\r\n Operating system \r\n | \r\n
Most CA activities are completed by using a web browser or other tool that connects to the CertAgent web interface. The CA supports seven web-based interfaces using different ports or URLs (Admin Site, CA Account Site, Public Site, RAMI (Registration Authority Management Interface), DBAccess, EST, and OCSP).
\r\nConfiguration data (including ACLs), most audit logs, certificates, and CRLs are stored in tables in a single database. In the evaluated configurations, the database is either HyperSQL or PostgreSQL and is hosted on the same physical system as the TOE. The connection to the database is not secured but is authenticated. Sensitive data stored in the database is encrypted before it is sent to the database for storage. The environmental JRE’s JDBC API is used to communicate with the database using a database vendor supplied JDBC driver.
\r\nCertAgent/Dhuma has an option to connect to LDAP servers to push certificate and CRLs as they are issued. Since certificates and CRLs are public information this connection may be unsecure or secure and may or may not be authenticated. There is no LDAP server in the evaluated configuration, LDAP publishing was not evaluated, and LDAP publishing is disabled when CertAgent/Dhuma is configured with strict NIAP compliance settings.
\r\nCertAgent/Dhuma’s OCSP capability is divided into basic OCSP support and enhanced OCSP support called Dhuma. Basic OCSP support provides OCSP responses solely for issuers managed by the CertAgent instance. If enabled, enhanced OCSP support, Dhuma, additionally provides OCSP responses for issuers not managed by the CertAgent/Dhuma instance and can be installed as an independent standalone OCSP responder. The evaluated configuration is a single system with CertAgent and enhanced OCSP (Dhuma) support enabled, but operating the TOE with basic OCSP support, with just CertAgent, or with just Dhuma, is considered equivalent.
\r\nCertAgent/Dhuma has an option to allow an external entity to supply revocation information through a client-authenticated REST-based API called the Dhuma API. There is no such external entity in the evaluated configuration, the Dhuma API was not evaluated, and the Dhuma API is disabled when the TOE is configured with strict NIAP compliance settings.
\r\nCertAgent/Dhuma has an option to send emails to subscribers and administrators through SMTP. There is no SMTP entity in the evaluated configuration, email notifications were not evaluated, and email notifications are disabled when CertAgent/Dhuma is configured with strict NIAP compliance settings.
\r\nPrivate keys used for issuing certificates, issuing CRLs, authenticating the TLS server, and signing OCSP responses reside in the environmental PKCS#11 Cryptographic Module. In the evaluated configuration, the PKCS#11 Cryptographic Module, is a Thales TCT T-5000 Luna Network HSM, but any PKCS#11 Cryptographic Module that is at least FIPS 140-2 Level 2 validated, provides hardware security of keys, includes a PKCS#11 library, and supports the required algorithms is considered equivalent. PKCS#11 is a C API exported from an explicitly linked shared library (a DLL or .so depending on platform called the PKCS#11 library) that is provided by the HSM vendor and resides in the operational environment. The TOE is configured with the path and filename of the PKCS#11 library, loads the PKCS#11 library when needed, and then calls functions in the PKCS#11 library. The PKCS#11 library is outside of the TOE and is part of the operational environment. Data traversing the interface between the TOE and the PKCS#11 library is protected by the environmental operating system in which processes are segregated into their own process space and are logically separated from all other processes by the operating system and underlying hardware. The TOE does not establish communication with the PKCS#11 Cryptographic Module (it does not establish a connection over USB, PCIe, or network to the PKCS#11 Cryptographic Module). Communication to the HSM occurs between the HSM vendor’s PKCS#11 library and the HSM both of which reside in the operational environment.
\r\nThe following components were used to create the test configurations:
\r\nSecurity Evaluation Summary: The evaluation was carried out in accordance with the Common Criteria Evaluation and Validation Scheme (CCEVS) process and scheme for the Protection Profile for Certification Authorities, version 2.1. The evaluation methodology used by the evaluation team to conduct the evaluation is the Common Methodology for Information Technology Security Evaluation, Version 3.1 release 5. The product, when delivered and configured as identified in the guidance documentation, satisfies all of the security functional requirements stated in the Information Security Corporation CertAgent v8.0 patch level 0.2 Security Target for Common Criteria Evaluation. The evaluation was completed in September 2024. Results of the evaluation can be found in the Common Criteria Evaluation and Validation Scheme Validation Report prepared by CCEVS.
","environmental_strengths":"Security Audit
\r\nThe TOE generates audit records of administrator, user, and its own activities. Audit data includes date, time, event type, subject identity, and other data as required. Most audit data are written to the database. Audit records indicating a database failure are stored in a local text file as the database is inaccessible. The TOE allows an external IT entity to access TOE audit records in the database by polling the TOE using the DBAccess REST API.
\r\nCommunications
\r\nThe TOE relies on the TLS/HyperText Transfer Protocol Secure (HTTPS) when transmitting sensitive data to and from applicable endpoints.
\r\nCertificate requests, certificates, CRLs, and OCSP responses are formed and verified according to RFC 5280, RFC 6960, and RFC 7030. Certificate validation is performed by the TOE.
\r\nSensitive data that needs to be recovered (authentication passwords) are encrypted using CMS, in conformance with RFC 5652, and then stored in the database. Sensitive data that does not need to be recovered, EST passwords, are not stored directly, but a check value is created, using PBKDF2/SHA-256, and stored.
\r\nCryptographic Support
\r\nCryptographic support is provided by two components.
\r\nISC CDK
\r\nThe ISC CDK is within the TOE’s boundary and is used by the TOE:
\r\nPKCS#11 Cryptographic Module
\r\nThe PKCS#11 Cryptographic Module is used by the TOE:
\r\nThe PKCS#11 Cryptographic Module securely stores the high value certificate authority keys and uses them to perform the signature operations that define a certificate authority. The PKCS#11 Cryptographic Module also securely stores the TLS/HTTPS server key and provides cryptographic services involving that key. PKCS#11 Cryptographic Modules often require a PIN or other authentication when the application using them starts and the TOE provides mechanisms for injecting this information during its startup procedures.
\r\nIn the evaluated configuration, the PKCS#11 Cryptographic Module is Thales TCT’s T-5000 Luna Network HSM.
\r\nUser Data Protection
\r\nThe TOE supports the creation of multiple certificate profiles by CA Administrators. Each profile is customizable by a CA Administrator and includes a certificate-based ACL of CA Operations Staff members allowed to issue or revoke certificates using the profile. Certificate requests are assigned a unique identifier upon submission that is used to link the request to the issued certificate.
\r\nThe TOE provides relying parties two methods to check the status of a certificate:
\r\nCRLs can be issued manually, on a schedule, or when a certificate is revoked for a set of configurable reason codes.
\r\nIdentification and Authentication
\r\nThe TOE uses two different identification and authentication methods, EST Authentication and Certificate-based Identification and Authentication, depending on the role and action being performed. Most TOE activities, and all activities involving the issuance or revocation of certificates, require certificate-based authentication.
\r\nPKCS#11 Cryptographic Modules support a variety of authentication options including passwords, smart cards, PED devices, and fingerprints. In all cases, someone must enable the PKCS#11 Cryptographic Module as part of the initialization of the TOE. This step is performed locally on the system during startup of the TOE.
\r\nAccess to the TOE’s local console is controlled by the underlying environmental operating system which performs the required identification and authentication when an administrator logs on.
\r\nEST Authentication
\r\nEST authentication supports certificate-based authentication or username/password authentication (over HTTPS) in cases where the EST user does not have a valid certificate.
\r\nFor username/password authentication (over HTTPS) privileged users in the CA Operation Staff role create and manage the username/password associations and assign each username a local CA policy controlling certificate issuance.
\r\nCertificate-based Identification and Authentication
\r\nAccess to the Admin Site, CA Account Site, DBAccess API, or RAMI API requires certificate-based client authentication using HTTPS. The functions available depend on the ACL and permissions that are assigned to the certificate used to authenticate.
\r\nThe portion of the Public Site allowing self-service revocation by subscribers also requires certificate-based client authentication using HTTPS.
\r\nSecurity Management
\r\nThe TOE is managed by authorized administrators using a web user interface and the local console as needed. All certificate issuance related administrative actions are performed via the web interface. The TOE supports three (3) roles (Administrator, Auditor, and CA Operations Staff) each of which consists of an access control list (ACL) of one or more X.509 certificates and one or more permissions (issue, revoke, RAMI, etc.).
\r\nOnly users who hold an administrator role in the TOE are allowed to have administrator privileges on the physical system on which the TOE is installed. They can:
\r\nProtection of the TSF
\r\nThe TOE encrypts any sensitive information, before it is sent to the environmental database, using the asymmetric “System” credential’s public key and the CMS format. These encrypted symmetric keys are the only symmetric keys that are persisted by the TOE. When the information is needed later, the encrypted data is retrieved from the database, and the TOE uses the “System” credential’s private key, via the PKCS#11 Cryptographic Module’s PKCS#11 API, to unwrap the symmetric key.
\r\nThe TOE maintains the password of PKCS#11 Cryptographic Module storing the “System” credential in memory until it exits. The TOE does not store, or directly use, any private keys (they are stored and protected by the PKCS#11 Cryptographic Module which performs operations with those keys at the TOE’s request). When the TOE shuts down all sensitive data in memory is cleared.
\r\nTOE Access
\r\nThe TOE’s Admin Site and CA Account Site display a warning banner prior to allowing any administrative actions to be performed. The TOE’s web interface will terminate sessions when they time out or when an authenticated user clicks the logout link in the navigation pane.
\r\nTrusted Path/Channels
\r\nThe TOE provides a trusted path/channel for secure communication between itself and external IT entities such as a registration authority (RA), audit server, or similar entities which are permitted to connect to the TOE, over client authenticated HTTPS/TLS. Privileged users accessing the TOE’s web interfaces also use a trusted path established and secured with client authenticated HTTPS/TLS. Subscribers with existing, valid certificates, also use a trusted path, established and secured with client authenticated HTTPS/TLS, to perform certificate renewal, via EST, or self-management, via the TOE’s Public Site web interface. Subscribers, and other non-privileged users, are permitted to connect to the TOE’s Public Site with unauthenticated HTTPS/TLS. Relying parties are permitted to connect to parts of the TOE’s Public Site, with either unauthenticated HTTPS/TLS or unprotected HTTP, to obtain certificate status or other information required to validate certificates issued by the TOE.
\r\nFor communication between the TOE and environmental components (notably the database and the HSM) the Operational Environment provides a non-encrypted, trusted channel. Secure communication is enforced between the TOE and IT entities in the Operational Environment using the Operational Environment’s JRE, JNDI, JDBC, and PKCS #11 Cryptographic Module components installed on the local system. These trusted channels transfer TOE data to and from IT entities within the Operational Environment.
","features":[{"id":141,"feature_name":"Asymmetric Key Generation"},{"id":135,"feature_name":"Auditing"},{"id":137,"feature_name":"Certificate Authentication"},{"id":2014,"feature_name":"Certificate Generation"},{"id":138,"feature_name":"Certificate Validation"},{"id":139,"feature_name":"Certification Authority"},{"id":144,"feature_name":"Cryptographic Hashing"},{"id":2016,"feature_name":"Cryptographic Key Establishment"},{"id":142,"feature_name":"Cryptographic Signature Generation"},{"id":143,"feature_name":"Cryptographic Signature Verification"},{"id":2017,"feature_name":"DRBG"},{"id":2013,"feature_name":"HTTPS Server"},{"id":140,"feature_name":"HTTPS Server without Mutual Authentication"},{"id":136,"feature_name":"Key Destruction"},{"id":145,"feature_name":"Keyed-hash message authentication"},{"id":2015,"feature_name":"Symmetric Key Generation"},{"id":2020,"feature_name":"TLS 1.2"},{"id":2012,"feature_name":"TLS Server with Mutual Authentication"}]}