National Information Assurance Partnership
Common Criteria Evaluation and Validation Scheme
Validation Report
Red Hat, Inc.
Red Hat® Certificate System 9.4
Report Number: CCEVS-VR-VID10831-2019
Dated: April 9, 2019
Version: 1.0
National Institute of Standards and Technology National Security Agency
Information Technology Laboratory Information Assurance Directorate
100 Bureau Drive 9800 Savage Road STE 6940
Gaithersburg, MD 20899 Fort George G. Meade, MD 20755-6940
Red Hat Certificate System 9.4 Validation Report Version 0.1, April 9, 2019
ii
ACKNOWLEDGEMENTS
Validation Team
Jennifer Dotson
Lisa Mitchell
Chris Thorpe
The MITRE Corporation
Bedford, MA
Ken Elliott
The Aerospace Corporation
Columbia, MD
Common Criteria Testing Laboratory
Cornelius Haley
Gossamer Security Solutions, Inc.
Catonsville, MD
Red Hat Certificate System 9.4 Validation Report Version 0.1, April 9, 2019
iii
Table of Contents
1 Executive Summary............................................................................................................1
2 Identification.......................................................................................................................1
3 Architectural Information...................................................................................................2
3.1 TOE Evaluated Platforms...........................................................................................3
3.2 TOE Architecture .......................................................................................................3
4 Security Policy....................................................................................................................6
4.1 Security audit..............................................................................................................6
4.2 Communication ..........................................................................................................6
4.3 Cryptographic support................................................................................................6
4.4 User data protection....................................................................................................6
4.5 Identification and authentication ................................................................................7
4.6 Security management .................................................................................................7
4.7 Protection of the TSF..................................................................................................7
4.8 TOE access .................................................................................................................8
4.9 Trusted path/channels.................................................................................................8
5 Assumptions .......................................................................................................................9
6 Clarification of Scope.........................................................................................................9
7 Documentation ...................................................................................................................9
8 IT Product Testing............................................................................................................10
8.1 Developer Testing ....................................................................................................10
8.2 Evaluation Team Independent Testing.....................................................................10
9 Evaluated Configuration...................................................................................................10
10 Results of the Evaluation..................................................................................................10
10.1 Evaluation of the Security Target (ASE)..................................................................10
10.2 Evaluation of the Development (ADV)....................................................................11
10.3 Evaluation of the Guidance Documents (AGD).......................................................11
10.4 Evaluation of the Life Cycle Support Activities (ALC)...........................................11
10.5 Evaluation of the Test Documentation and the Test Activity (ATE).......................12
10.6 Vulnerability Assessment Activity (VAN) ..............................................................12
10.7 Summary of Evaluation Results ...............................................................................13
11 Validator Comments/Recommendations..........................................................................13
12 Annexes ............................................................................................................................13
13 Security Target .................................................................................................................13
14 Glossary............................................................................................................................13
15 Bibliography.....................................................................................................................14
Red Hat Certificate System 9.4 Validation Report Version 0.1, April 9, 2019
1
1 Executive Summary
This report documents the assessment of the National Information Assurance Partnership
(NIAP) validation team of the evaluation of Red Hat Certificate System 9.4 provided by Red
Hat, Inc. It presents the evaluation results, their justifications, and the conformance results.
This Validation Report is not an endorsement of the Target of Evaluation by any agency of
the U.S. government, and no warranty is either expressed or implied.
The evaluation was performed by the Gossamer Security Solutions (Gossamer) Common
Criteria Testing Laboratory (CCTL) in Catonsville, MD, United States of America, and was
completed in April 2019. The information in this report is largely derived from the Evaluation
Technical Report (ETR) and associated test reports, all written by Gossamer Security
Solutions. The evaluation determined that the product is both Common Criteria Part 2
Extended and Part 3 Conformant and meets the assurance requirements of Protection Profile
for Certification Authorities, Version 2.1, 01 December 2017 (CAPP21).
The Target of Evaluation (TOE) is Red Hat Certificate System 9.4 batch update 3.
The TOE identified in this Validation Report has been evaluated at a NIAP approved
Common Criteria Testing Laboratory using the Common Methodology for IT Security
Evaluation (Version 3.1, Rev 4) for conformance to the Common Criteria for IT Security
Evaluation (Version 3.1, Rev 4). This Validation Report applies only to the specific version of
the TOE as evaluated. The evaluation has been conducted in accordance with the provisions
of the NIAP Common Criteria Evaluation and Validation Scheme and the conclusions of the
testing laboratory in the evaluation technical report are consistent with the evidence provided.
The validation team monitored the activities of the evaluation team, provided guidance on
technical issues and evaluation processes, and reviewed the individual work units and
successive versions of the ETR. The validation team found that the evaluation showed that the
product satisfies all of the functional requirements and assurance requirements stated in the
Security Target (ST). Therefore the validation team concludes that the testing laboratory’s
findings are accurate, the conclusions justified, and the conformance results are correct. The
conclusions of the testing laboratory in the evaluation technical report are consistent with the
evidence produced.
The technical information included in this report was obtained from the – Red Hat Certificate
System (CAPP21) Security Target, Version 1.0, April 9, 2019.and analysis performed by the
Validation Team.
2 Identification
The CCEVS is a joint National Security Agency (NSA) and National Institute of Standards
and Technology (NIST) effort to establish commercial facilities to perform trusted product
evaluations. Under this program, security evaluations are conducted by commercial testing
laboratories called Common Criteria Testing Laboratories (CCTLs) using the Common
Evaluation Methodology (CEM) in accordance with National Voluntary Laboratory
Assessment Program (NVLAP) accreditation.
Red Hat Certificate System 9.4 Validation Report Version 0.1, April 9, 2019
2
The NIAP Validation Body assigns Validators to monitor the CCTLs to ensure quality and
consistency across evaluations. Developers of information technology products desiring a
security evaluation contract with a CCTL and pay a fee for their product’s evaluation. Upon
successful completion of the evaluation, the product is added to NIAP’s Product Compliant
List.
Table 1 provides information needed to completely identify the product, including:
 The Target of Evaluation (TOE): the fully qualified identifier of the product as evaluated.
 The Security Target (ST), describing the security features, claims, and assurances of the
product.
 The conformance result of the evaluation.
 The Protection Profile to which the product is conformant.
 The organizations and individuals participating in the evaluation.
Table 1: Evaluation Identifiers
Item Identifier
Evaluation Scheme United States NIAP Common Criteria Evaluation and Validation Scheme
TOE Red Hat Certificate System 9.4
Protection Profile Protection Profile for Certification Authorities, Version 2.1, 01 December 2017
(CAPP21)
ST Red Hat® Certificate System (CAPP21) Security Target, Version 1.0, April 9,
2019
Evaluation Technical
Report
Evaluation Technical Report For Red Hat Certificate System 9.4, version 0.1,
April 9, 2019
CC Version Common Criteria for Information Technology Security Evaluation, Version 3.1,
rev 5
Conformance Result CC Part 2 extended, CC Part 3 conformant
Sponsor Red Hat, Inc.
Developer Red Hat, Inc.
Common Criteria
Testing Lab (CCTL)
Gossamer Security Solutions, Inc.
CCEVS Validators
3 Architectural Information
Note: The following architectural description is based on the description presented in the
Security Target.
The Red Hat Certificate System (RHCS) 9.4 is an application that issues and manages public-
key certificates. RHCS runs within Red Hat Enterprise Linux (RHEL 7.6), an operating
system that protects the subsystems of the TOE with Security-Enhanced Linux (SELinux)
policies and which provides secure network connections (using the TOE’s Tomcat’s
Red Hat Certificate System 9.4 Validation Report Version 0.1, April 9, 2019
3
HTTP/TLS to allow remote administration). RHCS provides proof of origin for issued
certificates as well as certificate status information through CRLs and OCSP responses.
RHCS verifies certificate related messages for issuance and revocation using signed CMC
requests and responses.
The RHCS is a software TOE that relies upon and incorporates different components in its
Operational Environment. RHCS runs within Red Hat Enterprise Linux (RHEL 7.6), an
operating system that protects the subsystems of the TOE with Security-Enhanced Linux
(SELinux) policies and which provides secure network connections (using the TOE’s
Tomcat’s HTTP/TLS to allow remote administration). The TOE integrates with a directory
server in its Operational Environment, such as Red Hat Directory Server and to provide an
internal data store. The underlying JSS and NSS in the RHEL operating system components
of the TOE support the use of PKCS#11 hardware devices that perform standards-oriented
cryptographic operations. All of the Operational Environment components along with the
TOE components represent an RHCS system.
3.1 TOE Evaluated Platforms
The evaluated configuration consists of The Target of Evaluation (TOE) is Red Hat
Certificate System 9.4 batch update 3 running on Red Hat Enterprise Linux (RHEL 7.6) an
utilizing a hardware security module for hardware based cryptographic security functions.
3.2 TOE Architecture
An RHCS system is composed of the following key components:
 Red Hat Certificate System (RHCS) - The Certificate System (CS) includes five
configurable subsystems that work together to manage enterprise PKI
deployments.
 Red Hat Enterprise Linux (RHEL) – The operating system (OS) in which RHCS
and other components execute. The OS includes the software cryptographic
module NSS, which supplies cryptographic functionality for TLS/HTTPS and
which supplies cryptographic functionality for RHEL’s package manager, RPM,
which verifies update packages.
 Hardware Security Module (HSM) - –An HSM provides the FIPS-certified
cryptographic services related to certificate management for the TOE. The HSM
provides secure key storage for private keys as well as cryptographic services to
allow secure use of stored keys (for example, using a stored key to sign a CRL).
The tested configuration includes a Thales nShield Connect 6000+ HSM, but any
HSM that is at least FIPS 140-2 Level 3 validated and provides hardware security
for keys and supports the required algorithms is considered equivalent.
 HTTP Engines (Tomcat (for all subsystems: CA, KRA, OCSP Responder, TPS,
and TKS)) - The web engine provides the HTML-based UI (presentation), REST
interface, and HTTP-based protocol handling. It does not perform authentication
and authorization other than providing and/or enforcing TLS. It performs basic
certificate validation and delegates all the application-specific authentication and
authorization to CS via a callback mechanism.
Red Hat Certificate System 9.4 Validation Report Version 0.1, April 9, 2019
4
 Internal Database (Red Hat Directory Server - RHDS 10.2) - The internal database
stores information such as certificates, requests, officer/administrator/auditor
information, and other information such as access control information. The CS
communicates with the internal database securely through TLS client
authentication.
The Certificate System is composed of the following subsystems running on one or more host
systems. A subsystem can reside on its own host system or be combined with other
subsystems on a single host system. While only the first three subsystems along with
command line tools (installed as part of the RHCS packages) are responsible for enforcing the
requirements of the CAPP21 Protection Profile requirements (i.e., they comprise the TSF),
one may use the other subsystems in an evaluated configuration to provide additional
functionality beyond the scope of the CAPP21. All RHCS subsystems share common
frameworks such as authentication, authorization, and auditing, as well as utilize the same
Operational Environment components.
 Certificate Authority (CA) - the subsystem that provides certificate management
functionality for issuing, renewing, revoking, and publishing certificates and
creating and publishing Certificate Revocation Lists (CRLs).
 Online Certificate Status Protocol (OCSP) Responder - a subsystem that provides
OCSP responder services, based on stored CA's CRLs to distribute the load for
certificate status verification.
 Key Recovery Authority (KRA) - a subsystem that provides private encryption key
storage and retrieval. In a Token Management System, the KRA’s HSM generates
key pairs for the clients when server-side key generation option is turned on.
 Token Key Service (TKS) - manages one or more master keys required to set up
secure channels from the tokens directly to the token processing system. The
secure channels provided by TKS allows Global Platform compliant smart cards
(tokens) to be identified with high level of confidence and subsequently
communicate securely with the RHCS servers for operations such as certificate
enrollments, renewals, server-side key generation requests, key archival and
recovery, etc.
 Token Processing System (TPS) - one unique function of the TPS is to provide
communication between Global Platform-compliant smart cards and the RHCS
subsystems by means of APDU (Application Protocol Data Unit). It provides the
registration authority functionality in the token management infrastructure and,
with the assistance of the TKS, establishes secure channels between the smart
cards and the back-end subsystems.
The CS subsystems (i.e., CA, KRA, OCSP Responder, TKS, and TPS) are highly integrated.
OCSP and CA subsystems work together on CRL publishing and certificate verification. CA
and KRA subsystems work together for key recovery and archival. Smart card tokens,
processed through the Enterprise Security Client (ESC) user interface, are managed by the
TPS. The TPS, however, works with at least two essential subsystems, a TKS to manage
shared secrets between the tokens and the collective Token Management System (TMS) and a
CA to process certificate enrollment operations. A TPS can also be configured to use a KRA
for server-side key generation and key archival and recovery, with the assistance of TKS to
deliver private keys securely to the tokens (smart cards).
Red Hat Certificate System 9.4 Validation Report Version 0.1, April 9, 2019
5
The CA, KRA, OCSP Responder, TPS, and TKS are implemented in Java, utilize a Tomcat
HTTP engine (see below), and share a common framework (also written in Java) for
management, logging, authentication, access control, self-tests, and notifications framework.
The following architectural diagrams show the interactions between various CS
configurations and various internal and external systems. Internally, the CS communicates
with an internal database where certificate records, request records, and system user records
are stored. The CS also accesses the cryptographic operations (directly or indirectly) via NSS.
The RHEL components within the TOE Boundary includes, the HTTP engine which manages
the presentation-level interaction between the CS and users including end-users, security
officers, auditors, and administrators. The CS may optionally publish certificates to a
corporate directory server.
In addition to the HTTP Engine and Internal Database, the CS also relies on access to
processing capabilities, file storage, as well as hardware and software cryptographic modules
provided by its Operational Environment.
Figure 3-1 RHCS System Architecture
Figure 3-1 above depicts the architecture of the different parts of the TOE (including its
RHCS [the upper portion] and RHEL [the lower, brown portion] components), the TOE’s
Operational Environment (OE), and external, authorized IT entities.
While a complete RHCS system includes all of the components indicated in Figure 3-1 the
RHCS TOE includes the components within the TOE boundary. Specifically, the TOE’s
RHCS components consists of the CA, OCSP Responder, KRA, TKS, and TPS subsystems
along with the command line utilities included with RHCS. The TOE’s RHEL components
include the NSS software cryptographic module and Tomcat server. The TSF portion of the
TOE consists of the CA, OCSP, and KRA subsystems, while the TOE’s OE includes other
components within RHEL (the internal LDAP DB, watchdog daemon, and an HSM). The
Red Hat Certificate System 9.4 Validation Report Version 0.1, April 9, 2019
6
TOE OE’s provides a Java GUI-based administration tool (called the “pkiconsole”).
Administrators use this “console” for administrative tasks such as managing users and
maintaining the different (CA, OCSP Manager, KRA, and TKS) subsystems and performing
daily operational and managerial duties for those subsystems.
4 Security Policy
This section summaries the security functionality of the TOE:
1. Security Audit
2. Communication
3. Cryptographic Support
4. User data protection
5. Identification and Authentication
6. Security Management
7. Protection of the TSF
8. TOE Access
9. Trusted Path/Channels
4.1 Security audit
The TOE generates logs for a range of security relevant events and relies upon its Operational
Environment (OE) for generation of operating system events. The 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 shuts down in the event of an error that prevents the TOE from creating
new audit records.
4.2 Communication
The TOE provides proof of origin for issued certificates through CRLs and OCSP responses.
The TOE also verifies certificate related messages using signed CMC requests and responses.
4.3 Cryptographic support
The TOE relies upon its OE for all cryptography and uses the OE-provided cryptography in
support of certificate issuance and related CA operations, in support of HTTPS, TLSS, and
TLSC operations.
4.4 User data protection
The TOE provides certificate profile functionality and certificate generation services
conforming to IETF RFC 5280. The TOE provides certificate status information through
CRLs and OCSP responses. The TOE clears sensitive data from buffers before releasing the
buffers.
Red Hat Certificate System 9.4 Validation Report Version 0.1, April 9, 2019
7
4.5 Identification and authentication
The TOE handles Certificate Management over CMS as both a client and server. The TOE
performs certificate path validation in conformance with IETF RFC 5280.
4.6 Security management
The 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. The TOE provides its available functions to CA administrators, CA operations
staff, Administrators/Officers, and Auditors.
4.7 Protection of the TSF
The RHCS TOE protects itself and also relies on supporting protections from other
components. At a high level, the TOE utilizes a separate and distinct hardware cryptographic
engine for critical cryptographic operations; the TOE makes effective use of SELinux security
mechanisms to protect itself and its underlying data and executables; the TOE command-line
tools do not operate on or modify live TOE data, but rather use the documented security
interfaces of the TOE to interact with the TOE; the TOE security functions are modular to
isolate them from potential errors in other components; and the TOE interfaces are well-
defined and restricted using a common certificate-based access control mechanism to
distinguish among and limit the functions of administrator roles.
The TOE protects itself primarily using its identification & authentication and access control
functions. With these functions, it ensures that users are properly authenticated and they are
authorized to perform the functions made available by the TOE. Users that cannot be
authenticated or that are not authorized will be denied access to applicable TOE functions.
The TOE relies on the components identified above for security and non-security functions.
The primary security functions involve protecting the TOE as it is executing or at rest within
its host, in facilitating secure inter-component communication, and providing FIPS-compliant
cryptographic services.
The host operating system and Java implementation are relied upon to provide a distinct and
separate execution environment for the TOE applications. In order to make effective use of
the operating system, all RHCS components are packaged utilizing standard Red Hat package
management (RPM). As such, whenever the TOE components are installed, they are stored
with “root” user and group ownership and utilize standard Linux directory, file, and
executable UNIX permissions. When an RHCS TOE instance is generated from these
installed components, a “pkiuser” user and group identifier is used for ownership of most
portions of the installed instances. The notable exceptions are (1) that an instance's start/stop
script is ONLY granted “root” ownership with read/write/execute permission available only to
root and (2) that the signed audit log files contained under the signedAudit directory contain a
group privilege of “pkiaudit” to allow separation of roles between auditors and administrators.
Files owned by “pkiuser” containing potentially sensitive information (e. g., log files,
configuration files such as CS.cfg, and NSS security database files) contain no privileges for
“other” users (e.g., file permissions of 00660 or 00600). Also, the entire contents of each PKI
instance’s signed audit directory are not accessible to “other” users. In practice, access to the
Red Hat Certificate System 9.4 Validation Report Version 0.1, April 9, 2019
8
“root” account is limited to administrators and the “pkiuser” account is configured so that it is
not used by any human user, but rather is used by TOE components.
While previous versions of the TOE operated in an unconfined SELinux domain, a SELinux
policy was created specifically to enhance the protection of RHCS. This policy includes the
following characteristics:
1. The files and directories delivered for each of the subsystems are labeled with specific
SELinux contexts (pki_ca_exec_t, pki_ca_var_lib_t, pki_ca_var_log_t, etc. for a CA for
example).
2. The ports used by each subsystem are labeled with specific SELinux contexts
(pki_ca_port, pki_tps_port, etc.).
3. The CS subsystem processes are also constrained to run within specific SELinux
domains (pki_ca_t, pki_ra_t, pki_ocsp_t, etc.). When processes are started, they start in
the unconfined_t domain, but transition into their assigned domain.
4. Each SELinux domain has rules written to specify the actions that are authorized for the
domain. As an example, the pki_ca_t domain has rules written to allow write-access
files with context pki_ca_var_log_t. Moreover, it has rules to allow processes running
within the domain to connect to ports of type pki_ca_port (as well as others).
5. All accesses not specified in the policy are denied.
Ultimately, the operating system with SELinux extensions is configured to protect the TOE
and its stored data using the core access control mechanisms and SELinux domain protection
mechanisms.
The TOE also relies on its security providers (JSS/NSS) and web engines primarily to
facilitate secure (TLS/HTTPS) communications between TOE components and also with
TOE clients. While the TOE can support a number of cipher suites with RSA and ECC key
exchange, limiting TLS ciphers to FIPS compliant algorithms is encouraged.
Finally, the TOE depends on a FIPS validated HSM to provide the underlying cryptographic
support necessary to allow the TOE to securely act as a certificate authority (signing/issuing
certificates and revocation information [CRL and OCSP]). The TOE accesses the HSM via a
corresponding library installed on the host operating system. The HSM stores critical keys so
that they are not externally accessible. It provides access to its embedded keys in order to
generate new keys, encrypt/decrypt data, produce signatures, etc. In practice, the TOE is the
sole user or client of the HSM attached directly to its host operating system.
4.8 TOE access
The TOE offers an administrator configurable timeout after which to lock remote interactive
sessions as well as allowing 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.
4.9 Trusted path/channels
The TOE protects interactive communication with administrators on the HTTPS (WebUI)
interface, the set of TLS protected command line tools, and the pkiconsole application that
utilizes HTTPS protected REST API interfaces. In each case, both integrity and disclosure
protection are ensured. If the negotiation of an encrypted session fails or if the user does not
Red Hat Certificate System 9.4 Validation Report Version 0.1, April 9, 2019
9
have authorization for remote administration, the attempted connection will not be
established.
The TOE protects communication with network peers, such as a directory services, using TLS
connections to prevent unintended disclosure or modification of data.
5 Assumptions
The Security Problem Definition, including the assumptions, may be found in the following
documents:
 Protection Profile for Certification Authorities, Version 2.1, 01 December 2017
(CAPP21)
That information has not been reproduced here and the CAPP21 should be consulted if there
is interest in that material.
The scope of this evaluation was limited to the functionality and assurances covered in the
CAPP21as described for this TOE in the Security Target. Other functionality included in the
product was not assessed as part of this evaluation. All other functionality provided by the
devices needs to be assessed separately, and no further conclusions can be drawn about their
effectiveness.
6 Clarification of Scope
All evaluations (and all products) have limitations, as well as potential misconceptions that
need clarification. This text covers some of the more important limitations and clarifications
of this evaluation. Note that:
 As with any evaluation, this evaluation only shows that the evaluated configuration
meets the security claims made with a certain level of assurance (the assurance
activities specified in the Protection Profile for Certification Authorities and
performed by the evaluation team).
 This evaluation covers only the specific device models and software as identified in
this document, and not any earlier or later versions released or in process.
 This evaluation did not specifically search for, nor attempt to exploit, vulnerabilities
that were not “obvious” or vulnerabilities to objectives not claimed in the ST. The
CEM defines an “obvious” vulnerability as one that is easily exploited with a
minimum of understanding of the TOE, technical sophistication and resources.
 The functionality evaluated is scoped exclusively to the security functional
requirements specified in the CAPP21 and applicable Technical Decisions. Any
additional security related functional capabilities of the TOE were not covered by this
evaluation.
7 Documentation
The following documents were available with the TOE for evaluation:
Red Hat Certificate System 9.4 Validation Report Version 0.1, April 9, 2019
10
 Red Hat Certificate System 9.4 Administration Guide (Common Criteria Edition)
 Red Hat Certificate System 9.4 Planning, Installation, and Deployment Guide
(Common Criteria Edition)
8 IT Product Testing
This section describes the testing efforts of the developer and the Evaluation Team. It is
derived from information contained in the Assurance Activity Report (CAPP21) for Red Hat
Certificate System, Version 0.3, April 9, 2019 (AAR).
8.1 Developer Testing
No evidence of developer testing is required in the assurance activities for this product.
8.2 Evaluation Team Independent Testing
The evaluation team verified the product according a Common Criteria Certification
document and ran the tests specified in the CAPP21 including the tests associated with
optional requirements.
The details of the test configuration are specified in the Assurance Activity Report (CAPP21)
for Red Hat Certificate System, Version 0.3, April 9, 2019. Of note is that the TOE was tested
in a virtual machine environment provided by Windows Server 2012 R2, as specified in
section 3.4.1 of that document.
9 Evaluated Configuration
The evaluated configuration consists of The Target of Evaluation (TOE) is Red Hat
Certificate System 9.4 batch update 3 running on Red Hat Enterprise Linux (RHEL 7.6) an
utilizing a hardware security module for hardware based cryptographic security functions.
10 Results of the Evaluation
The results of the assurance requirements are generally described in this section and are
presented in detail in the proprietary ETR. The reader of this document can assume that all
assurance activities and work units received a passing verdict.
A verdict for an assurance component is determined by the resulting verdicts assigned to the
corresponding evaluator action elements. The evaluation was conducted based upon CC
version 3.1 rev 4 and CEM version 3.1 rev 4. The evaluation determined the Red Hat
Certificate System 9.4 TOE to be Part 2 extended, and to meet the SARs contained in the
CAPP21.
10.1 Evaluation of the Security Target (ASE)
The evaluation team applied each ASE CEM work unit. The ST evaluation ensured the ST
contains a description of the environment in terms of policies and assumptions, a statement of
Red Hat Certificate System 9.4 Validation Report Version 0.1, April 9, 2019
11
security requirements claimed to be met by the Red Hat Certificate System 9.4 products that
are consistent with the Common Criteria, and product security function descriptions that
support the requirements.
The validator reviewed the work of the evaluation team, and found that sufficient evidence
and justification was provided by the evaluation team to confirm that the evaluation was
conducted in accordance with the requirements of the CEM, and that the conclusion reached
by the evaluation team was justified.
10.2 Evaluation of the Development (ADV)
The evaluation team applied each ADV CEM work unit. The evaluation team assessed the
design documentation and found it adequate to aid in understanding how the TSF provides the
security functions. The design documentation consists of a functional specification contained
in the Security target and Guidance documents. Additionally, the evaluator performed the
assurance activities specified in the CAPP21 related to the examination of the information
contained in the TSS.
The validator reviewed the work of the evaluation team, and found that sufficient evidence
and justification was provided by the evaluation team to confirm that the evaluation was
conducted in accordance with the requirements of the CEM, and that the conclusion reached
by the evaluation team was justified.
10.3 Evaluation of the Guidance Documents (AGD)
The evaluation team applied each AGD CEM work unit. The evaluation team ensured the
adequacy of the user guidance in describing how to use the operational TOE. Additionally,
the evaluation team ensured the adequacy of the administrator guidance in describing how to
securely administer the TOE. All of the guides were assessed during the design and testing
phases of the evaluation to ensure they were complete.
The validator reviewed the work of the evaluation team, and found that sufficient evidence
and justification was provided by the evaluation team to confirm that the evaluation was
conducted in accordance with the requirements of the CEM, and that the conclusion reached
by the evaluation team was justified.
10.4 Evaluation of the Life Cycle Support Activities (ALC)
The evaluation team applied each ALC CEM work unit. The evaluation team found that the
TOE was identified.
The validator reviewed the work of the evaluation team, and found that sufficient evidence
and justification was provided by the evaluation team to confirm that the evaluation was
conducted in accordance with the requirements of the CEM, and that the conclusion reached
by the evaluation team was justified.
Red Hat Certificate System 9.4 Validation Report Version 0.1, April 9, 2019
12
10.5 Evaluation of the Test Documentation and the Test Activity (ATE)
The evaluation team applied each ATE CEM work unit. The evaluation team ran the set of
tests specified by the assurance activities in the CAPP21 and recorded the results in a Test
Report, summarized in the AAR.
The validator reviewed the work of the evaluation team, and found that sufficient evidence
and justification was provided by the evaluation team to confirm that the evaluation was
conducted in accordance with the requirements of the CEM, and that the conclusion reached
by the evaluation team was justified.
10.6 Vulnerability Assessment Activity (VAN)
The evaluation team applied each AVA CEM work unit. The vulnerability analysis is in the
Detailed Test Report (DTR) prepared by the evaluator. The vulnerability analysis includes a
public search for vulnerabilities.
1. On the February 26, 2019, the evaluator searched the following sources for
vulnerabilities:
 National Vulnerability Database (https://web.nvd.nist.gov/vuln/search),
 Vulnerability Notes Database (http://www.kb.cert.org/vuls/),
 Rapid7 Vulnerability Database (https://www.rapid7.com/db/vulnerabilities),
 Tipping Point Zero Day Initiative (http://www.zerodayinitiative.com/advisories ),
 Exploit / Vulnerability Search Engin (http://www.exploitsearch.net),
 SecurITeam Exploit Search (http://www.securiteam.com),
 Tenable Network Security (http://nessus.org/plugins/index.php?view=search),
 Offensive Security Exploit Database (https://www.exploit-db.com/)
2. Each site was searched using the following terms:
a. RHCS
b. RHEL
c. Thales
d. nShield
e. Certificate Authority
f. NSS
g. tomcat
h. TLS
The public search for vulnerabilities did not uncover any residual vulnerability. The validator
reviewed the work of the evaluation team and found that sufficient evidence and justification
was provided by the evaluation team to confirm that the evaluation was conducted in
Red Hat Certificate System 9.4 Validation Report Version 0.1, April 9, 2019
13
accordance with the requirements of the CEM, and that the conclusion reached by the
evaluation team was justified.
10.7 Summary of Evaluation Results
The evaluation team’s assessment of the evaluation evidence demonstrates that the claims in
the ST are met. Additionally, the evaluation team’s testing also demonstrated the accuracy of
the claims in the ST.
The validation team’s assessment of the evidence provided by the evaluation team is that it
demonstrates that the evaluation team followed the procedures defined in the CEM, and
correctly verified that the product meets the claims in the ST.
11 Validator Comments/Recommendations
The validation team notes that the evaluated configuration is dependent upon the TOE being
configured per the evaluated configuration instructions in the. Common Criteria Supplemental
User Guide. No versions of the TOE and software, either earlier or later were evaluated.
Please note that the functionality evaluated is scoped exclusively to the security functional
requirements specified in the Security Target. Other functionality included in the product was
not assessed as part of this evaluation. Other functionality provided by devices in the
operational environment, such as the audit server, need to be assessed separately and no
further conclusions can be drawn about their effectiveness.
12 Annexes
Not applicable
13 Security Target
The Security Target is identified as: Red Hat® Certificate System (CAPP21) Security Target,
Version 1.0, April 9, 2019.
14 Glossary
The following definitions are used throughout this document:
 Common Criteria Testing Laboratory (CCTL). An IT security evaluation facility
accredited by the National Voluntary Laboratory Accreditation Program (NVLAP) and
approved by the CCEVS Validation Body to conduct Common Criteria-based evaluations.
 Conformance. The ability to demonstrate in an unambiguous way that a given
implementation is correct with respect to the formal model.
 Evaluation. The assessment of an IT product against the Common Criteria using the
Common Criteria Evaluation Methodology to determine whether or not the claims made
are justified; or the assessment of a protection profile against the Common Criteria using
the Common Evaluation Methodology to determine if the Profile is complete, consistent,
Red Hat Certificate System 9.4 Validation Report Version 0.1, April 9, 2019
14
technically sound and hence suitable for use as a statement of requirements for one or
more TOEs that may be evaluated.
 Evaluation Evidence. Any tangible resource (information) required from the sponsor or
developer by the evaluator to perform one or more evaluation activities.
 Feature. Part of a product that is either included with the product or can be ordered
separately.
 Target of Evaluation (TOE). A group of IT products configured as an IT system, or an
IT product, and associated documentation that is the subject of a security evaluation under
the CC.
 Validation. The process carried out by the CCEVS Validation Body leading to the issue
of a Common Criteria certificate.
 Validation Body. A governmental organization responsible for carrying out validation
and for overseeing the day-to-day operation of the NIAP Common Criteria Evaluation and
Validation Scheme.
15 Bibliography
The Validation Team used the following documents to produce this Validation Report:
[1] Common Criteria for Information Technology Security Evaluation: Part 1:
Introduction and General Model, Version 3.1, Revision 5, April 2017.
[2] Common Criteria for Information Technology Security Evaluation Part 2: Security
functional components, Version 3.1, Revision 5, April 2017.
[3] Common Criteria for Information Technology Security Evaluation Part 3: Security
assurance components, Version 3.1 Revision 5, April 2017.
[4] Protection Profile for Certification Authorities, Version 2.1, 01 December 2017
(CAPP21).
[5] Red Hat® Certificate System (CAPP21) Security Target, Version 1.0, April 9, 2019
(ST).
[6] Assurance Activity Report (CAPP21) for Red Hat Certificate System, Version 0.3,
April 9, 2019 (AAR).
[7] Detailed Test Report (CAPP21) for RedHat Certificate Services, Version 0.2, April 4,
2019 (DTR).
[8] Evaluation Technical Report for Red Hat Certificate System 9.4, Version 0.1, April 9,
2019 (ETR).