B.2. Example Common Criteria Installations

These example provide explicit and detailed configuration examples for both token management and non-token management deployments. These use example server names, users, and other configuration options.

B.2.1. Non-TMS Common Criteria Setup Procedures

These are the instructions for establishing a Common Criteria test environment for a Non-TMS (Token Management System). Throughout this document, reference links to the Red Hat Certificate System 8.1 Guidance documents have been provided for users as either a well-documented stand-alone procedure, or as an optional source of additional information, and well be clearly denoted as to their purpose.

NOTE

For the purposes of this test, everything is installed/configured on a single machine.

B.2.1.1. Prerequisites: RHEL 5.6 Operating System Installation and Configuration

B.2.1.1.1. Non-TMS Inventory
This test requires a single 64-bit x86_64 machine containing a 64-bit version of the Red Hat Enterprise Linux (RHEL) Server release 5.6 operating system for the x86_64 architecture. The machine, which for the purposes of this document will be referred to with a hostname of server.example.com, should be registered with Red Hat Network (RHN) so that it may be fully updated with the latest packages for this version of the operating system. For example, once the operating system has been installed, this can be accomplished by becoming the root user, and executing the following command:
[root@server]# yum -y update

NOTE

In the command listed above, [root@server]# is merely an example command-line prompt. This convention is used throughout this document.
Additionally, the user will need to have an nCipher nShield Hardware Security Module (HSM) attached to this machine for compliance with FIPS 140-2 (Level 3). Details for installation and configuration of this device are provided in Section B.2.1.1.2, “Hardware Security Module Installation”. For configuring FIPS mode, see the hardware vendor documentation.
Finally, for the purposes of Common Criteria certification of a non-TMS, the user will need to have the appropriate Red Hat subscriptions to download and install the following applications to this machine (detailed download, installation, and configuration instructions are provided below in various sections of this document):
  • Tomcat 5.5.23
  • Red Hat Directory Server 8.2
  • Red Hat Certificate System 8.1 subsystems:
    • Certificate Authority (CA)
    • Data Recovery Management (DRM) - also called a Key Recovery Authority (KRA)
    • Online Certificate Status Protocol (OCSP) Responder
  • Red Hat Certificate System (Red Hat Certificate System) 8.1 Console
  • Firefox 3.x
  • Open JDK/JRE 1.6
  • JSS 4.6
  • NSS 3.12
  • nss-tools 3.12
  • mozldap-tools
B.2.1.1.2. Hardware Security Module Installation
If the nCipher nShield is not setup, insert the accompanying DVD, or mount the ISO and cd into the "Documents" folder. For example, assuming that the ISO is available in /tmp:
[root@server]# mkdir /mnt/iso
[root@server]# cd /mnt/iso/document
[root@server]# mount -o loop /tmp/nCSS_linux64_user_11_40.iso /mnt/iso/
[root@server]# ls
dr-xr-xr-x 2 root root    2048 Aug  2  2010 netHSM
-r-xr-xr-x 1 root root  967656 Aug  2  2010 nShield_Connect_Physical_Security_Checklist.pdf
-r-xr-xr-x 1 root root  310693 Aug  2  2010 nShield_Connect_Quick_Start_Guide.pdf
-r-xr-xr-x 1 root root 2409806 Aug  2  2010 nShield_Connect_User_Guide.pdf
-r-xr-xr-x 1 root root  610234 Aug  2  2010 nShield_Hardware_Installation.pdf
-r-xr-xr-x 1 root root  278386 Aug  2  2010 nShield_Quick_Start_Guide.pdf
-r-xr-xr-x 1 root root 2449190 Aug  2  2010 nShield_User_Guide.pdf
-r-xr-xr-x 1 root root  255087 Aug  2  2010 nToken_Install_Guide.pdf
Follow the vendor's instructions to setup the nCipher nShield.
Once the nCipher nShield has been installed, ensure that the connection status is OK (by using grep):
[root@server]# /opt/nfast/bin/enquiry | grep -i status
 connection status    OK
To enable FIPS mode, open the security UI:
/opt/nfast/bin/ksafe
In the 'Security World' tab, make sure that "Strict FIPS 140-2 Level III" is set to yes.
For configuring FIPS mode, see the hardware vendor documentation.
B.2.1.1.3. SELinux Enforcement
SELinux is a collection of mandatory access control rules which are enforced across a system to restrict unauthorized access and tampering.
Red Hat recommends running Certificate System with SELinux in enforcing mode, to make the most of the security policies.
The /usr/sbin/getenforce command will give the status of SELinux. If running /usr/sbin/getenforce returns a result of either disabled or permissive, then it needs to be enabled to enforcing. As the root user, edit the file /etc/sysconfig/selinux and set SELINUX=Enforcing, then reboot the system.
[root@server]# /usr/sbin/getenforce
Enforcing
[root@server]# /usr/sbin/sestatus
SELinux status:                 enabled
SELinuxfs mount:                /selinux
Current mode:                   enforcing
Mode from config file:          enforcing
Policy version:                 21
Policy from config file:        targeted
B.2.1.1.4. Operating System User and Group Creation
This test requires that certain operating system users and groups exist. Log into the RHEL 5.6 machine as super user and ensure that both the UID and the GID of pkiuser are 17:
[root@server]# grep pkiuser /etc/group
pkiuser:x:17:
[root@server]# grep pkiuser /etc/passwd
pkiuser:x:17:17:Red Hat Certificate System:/usr/share/pki:/sbin/nologin
In the event that the pkiuser group is not present, make certain that the appropriate tool packages are installed and recheck the pkiuser user and group:
[root@server]# rpm -q setup
setup-2.5.58-7.el5
[root@server]# rpm -q shadow-utils
shadow-utils-4.0.17-15.el5
If the pkiuser user or group are still not present, add them:
[root@server]# /usr/sbin/groupadd -g 17 -r pkiuser
[root@server]# /usr/sbin/useradd -g pkiuser -d /usr/share/pki -s /sbin/nologin -c "Red Hat Certificate System" -u 17 -r pkiuser
If the pkiuser user or group exist but do not have a uid:gid of 17:17, reset the values:
[root@server]# /usr/sbin/userdel pkiuser
[root@server]# /usr/sbin/groupdel pkiuser
[root@server]# /usr/sbin/groupadd -g 17 -r pkiuser
[root@server]# /usr/sbin/useradd -g pkiuser -d /usr/share/pki -s /sbin/nologin -c "Red Hat Certificate System" -u 17 -r pkiuser
Create an administration group:
[root@server]# /usr/sbin/groupadd -r pkiadmin
Create an auditor group:
[root@server]# /usr/sbin/groupadd -r pkiaudit

Note

Linux distinguishes system users such as pkiuser (which are often referred to as daemons which have no real person associated with them) from standard users that comprise the PKI administrators, agents, and auditors which are associated with real people.
 
Optional Reference: Users and Groups
If they do not already exist, create standard user accounts for either pkiadmin or pkiaudit, but never allow any standard user access to both groups.
For example, to create an administrator called John Smith:
[root@server]# /usr/sbin/useradd -g pkiadmin -d /home/jsmith -s /bin/bash -c
"Red Hat Certificate System Administrator" -m jsmith
For example, to create an auditor called Sally Jones:
[root@server]# /usr/sbin/useradd -g pkiaudit -d /home/sjones -s /bin/bash -c
"Red Hat Certificate System Auditor" -m sjones
B.2.1.1.5. Operating System User and Group Association
Once all operating system groups have been established (see Section B.2.1.1.4, “Operating System User and Group Creation”), the pkiuser system user must be associated with both the pkiadmin and the pkiaudit groups:
[root@server]# /usr/sbin/usermod -a -G pkiadmin pkiuser
[root@server]# /usr/sbin/usermod -a -G pkiaudit pkiuser

Important

The pkiuser user is allowed to be associated with both the pkiadmin and the pkiaudit groups because pkiuser is a system user. Regular users are never allowed to be associated with both groups because no regular user is ever allowed to be both an administrator and an auditor.
If a pre-existing user is re-assigned to become an administrator, they can be associated with the pkiadmin group:
[root@server]# grep mnelson /etc/group
mnelson:x:1099:
[root@server]# grep mnelson /etc/passwd
mnelson:x:1099:1099:Mary Nelson:/home/mnelson:/bin/bash
[root@server]# /usr/sbin/usermod -a -G pkiadmin mnelson
Similarly, if a pre-existing user is re-assigned to become an auditor, they can be associated with the pkiaudit group:
[root@server]# grep blarson /etc/group
blarson:x:1257:
[root@server]# grep blarson /etc/passwd
blarson:x:1257:1257:Bob Larson:/home/blarson:/bin/bash
[root@server]# /usr/sbin/usermod -a -G pkiaudit blarson
Additionally, since this test utilizes an nCipher nShield HSM, both the 'pkiuser' user and any individuals in charge of administration of this device must be associated with the 'nfast' group:
[root@server]# /usr/sbin/usermod -a -G nfast pkiuser
[root@server]# /usr/sbin/usermod -a -G nfast jsmith
[root@server]# /usr/sbin/usermod -a -G nfast mnelson
Once all associations have been generated, ensure that the groups for users 'pkiuser', 'jsmith', 'sjones', 'mnelson', and 'blarson' are correct:
[root@server]# groups pkiuser jsmith sjones mnelson blarson
pkiuser : pkiuser pkiadmin pkiaudit nfast
jsmith : pkiadmin nfast
sjones : pkiaudit
mnelson : mnelson pkiadmin nfast
blarson : blarson pkiaudit

B.2.1.2. Red Hat Certificate System 8.1 Subsystem Packages

B.2.1.2.1. Directory Server Subsystem Package Installation
This machine has been registered with Red Hat Network (RHN) to contain the appropriate Red Hat subscriptions to download and install Red Hat Directory Server 8.2 (see Section B.2.1.1, “Prerequisites: RHEL 5.6 Operating System Installation and Configuration”).

NOTE

Check the /etc/yum.repos.d/ directory for the existence of either 'epel.repo' or 'epel-testing.repo'. If either file is present, make certain that ALL sections in both 'epel.repo' and 'epel-testing.repo' have been set to 'enabled=0' so that no EPEL packages accidentally override the officially desired RHEL RPMS.
Install the OpenLDAP tools:
[root@server]# yum install openldap-clients
To install all of the Red Hat Directory Server 8.2 packages, perform the following command:
[root@server]# yum install redhat-ds
B.2.1.2.2. Certificate System Subsystem Package Installation
This machine has been registered with Red Hat Network (RHN) to contain the appropriate Red Hat subscriptions to download and install Red Hat Certificate System 8.1 (see Section B.2.1.1, “Prerequisites: RHEL 5.6 Operating System Installation and Configuration”).

NOTE

Check the /etc/yum.repos.d/ directory for the existence of either 'epel.repo' or 'epel-testing.repo'. If either file is present, make certain that ALL sections in both 'epel.repo' and 'epel-testing.repo' have been set to 'enabled=0' so that no EPEL packages accidentally override the officially desired RHEL RPMS.
To install all of the Red Hat Certificate System 8.1 packages necessary for this test, perform the following commands:
[root@server]# yum install pki-ca
[root@server]# yum install pki-kra
[root@server]# yum install pki-ocsp
[root@server]# yum install pki-console
[root@server]# yum -y update

B.2.1.3. Hardware Security Module SELinux Context

Prior to creating any Red Hat Certificate System 8.1 instances, since this test requires using an nCipher nShield HSM (see Section B.2.1.1.2, “Hardware Security Module Installation”), restore the SELinux context by running the 'restorecon' command as the super user and restart the nCipher nShield HSM:
[root@nontps]#  restorecon -R /opt/nfast
[root@nontps]#  restorecon -R /dev/nfast
[root@nontps]#  /opt/nfast/sbin/init.d-ncipher restart

Important

This procedure must be executed AFTER installation of the 'pki-selinux' package but BEFORE any Red Hat Certificate System 8.1 instance is created, and must be executed once on every machine hosting an HSM-based Red Hat Certificate System 8.1 instance.

B.2.1.4. Directory Server Instance Installation and Configuration

Since Red Hat Directory Server 8.2 has been installed on this machine (see Section B.2.1.2.1, “Directory Server Subsystem Package Installation”), the user should now install and configure a Red Hat Directory Server 8.2 instance appropriate for use by the Red Hat Certificate System 8.1 instances required for this test.

Important

The Certificate System SELinux policies assume that the Red Hat Directory Server is listening over the standard LDAP/LDAPS ports, 389 and 636, respectively.
 
Additionally, for the purposes of this test, this document uses a convention of all passwords being "Secret123".
To install a Red Hat Directory Server 8.2 instance appropriate for use by the Red Hat Certificate System 8.1 instances included in this test, perform the instructions in the following procedural reference choosing default values:
Procedural Reference: RHDS 8.2: Typical Setup

B.2.1.5. CA Instance Creation and Configuration

B.2.1.5.1. CA Instance Creation
Use the pkicreate tool to create an Red Hat Certificate System 8.1 instance of a CA.

Note

Make certain that the "-audit_group=pkiaudit" parameter is used.
Use the 'pkicreate' tool as shown below:
[root@server]# pkicreate -pki_instance_root=/var/lib        \
                           -pki_instance_name=pki-ca          \
                           -subsystem_type=ca                 \
                           -agent_secure_port=9443            \
                           -ee_secure_port=9444               \
                           -ee_secure_client_auth_port=9446   \
                           -admin_secure_port=9445            \
                           -unsecure_port=9180                \
                           -tomcat_server_port=9701           \
                           -user=pkiuser                      \
                           -group=pkiuser                     \
                           -audit_group=pkiaudit              \
                           -redirect conf=/etc/pki-ca         \
                           -redirect logs=/var/log/pki-ca     \
                           -verbose
B.2.1.5.2. Directory Server SSL Server Authentication Configuration (Temporary)

Note

This section creates a temporary server certificate and temporary self-signed CA to establish SSL communication between the Red Hat Directory Server and the Red Hat Certificate System CA during its configuration. These certificates will be replaced in Section B.2.1.5.5, “Directory Server SSL Server Authentication Configuration (Trusted)”.
Stop the CA instance before modifying its NSS security databases:
[root@server]# /sbin/service pki-ca stop
Stopping pki-ca: ..                                        [  OK  ]
Stop the Red Hat Directory Server instance before modifying its NSS security databases:
[root@server]# /sbin/service dirsrv stop
Shutting down dirsrv:
    server...                                            [  OK  ]
Make a backup of Red Hat Directory Server contents:
[root@server]# cd /etc/dirsrv/slapd-server/
[root@server]# ls
cert8.db      dse.ldif      dse.ldif.startOK   key3.db  secmod.db
certmap.conf  dse.ldif.bak  dse_original.ldif  schema   slapd-collations.conf
[root@server]# tar -cf /tmp/db-backup.tar *
Using a password file, establish a password for the existing NSS security databases:
[root@server]# echo Secret123 > /tmp/pwdfile
[root@server]# /usr/bin/certutil -W -d . -f /tmp/pwdfile
[root@server]# /usr/bin/certutil -L -d /etc/dirsrv/slapd-server

Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI
Create a temporary Self-Signed CA certificate for LDAP:

NOTE

In the command below, an unlimited path length is specified by a negative one (-1).
[root@server]# /usr/bin/certutil -S -n "LDAP Self Signed CA certificate" -s "cn=LDAPCA-cert,dc=example,dc=com" -2 -x -t "CT,," -m 1000 -v 120 -d . -k rsa -f /tmp/pwdfile

A random seed must be generated that will be used in the
creation of your key.  One of the easiest ways to create a
random seed is to use the timing of keystrokes on a keyboard.

To begin, type keys on the keyboard until this progress meter
is full.  DO NOT USE THE AUTOREPEAT FUNCTION ON YOUR KEYBOARD!


Continue typing until the progress meter is full:

|************************************************************|

Finished.  Press enter to continue:


Generating key.  This may take a few moments...

Is this a CA certificate [y/N]?
y
Enter the path length constraint, enter to skip [<0 for unlimited path]: > -1
Is this a critical extension [y/N]?
y
[root@server]# /usr/bin/certutil -L -d /etc/dirsrv/slapd-server

Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI

LDAP Self Signed CA certificate                              CTu,u,u
Create a temporary Server Cert (and sign it using the temporary CA certificate created above):
[root@server]# /usr/bin/certutil -S -n "Server-Cert-ldap" -s "cn=server.example.com" -c "LDAP Self Signed CA certificate" -t "u,u,u" -m 1001 -v 120 -d . -k rsa -f /tmp/pwdfile

A random seed must be generated that will be used in the
creation of your key.  One of the easiest ways to create a
random seed is to use the timing of keystrokes on a keyboard.

To begin, type keys on the keyboard until this progress meter
is full.  DO NOT USE THE AUTOREPEAT FUNCTION ON YOUR KEYBOARD!


Continue typing until the progress meter is full:

|************************************************************|

Finished.  Press enter to continue:


Generating key.  This may take a few moments...
[root@server]# /usr/bin/certutil -L -d /etc/dirsrv/slapd-server

Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI

Server-Cert-ldap                                             u,u,u
LDAP Self Signed CA certificate                              CTu,u,u
Start the Red Hat Directory Server instance:
[root@server]# /sbin/service dirsrv start
Starting dirsrv:
    server...                                            [  OK  ]
Create an LDIF file by running the following command:

NOTE

In the command listed below, "> " is merely the command-line prompt; do NOT type these initial two characters.
[root@server]# cat <<EOF > /tmp/example.ldif
> dn: cn=config
> changetype: modify
> replace: nsslapd-security
> nsslapd-security: on
> -
> replace: nsslapd-securePort
> nsslapd-secureport: 636
>
> dn: cn=encryption,cn=config
> changetype: modify
> replace: nsssl3
> nsssl3: on
> -
> replace: nsssl3ciphers
> nsssl3ciphers: -rsa_null_md5,+rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5,+rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fortezza_rc4_128_sha,+fortezza_null,+tls_rsa_export1024_with_rc4_56_sha,+tls_rsa_export1024_with_des_cbc_sha
> -
> replace: nssslclientauth
> nssslclientauth: allowed
>
> dn: cn=RSA,cn=encryption,cn=config
> changetype: add
> objectclass: top
> objectclass: nsEncryptionModule
> cn: RSA
> nsssltoken: internal (software)
> nssslpersonalityssl: Server-Cert-ldap
> nssslactivation: on
> EOF
Enable SSL in the LDAP Server by running the following command:
[root@server]# /usr/bin/ldapmodify -x -h server.example.com  -p 389 -D "cn=Directory Manager" -w Secret123 -f /tmp/example.ldif
modifying entry "cn=config"

modifying entry "cn=encryption,cn=config"

adding new entry "cn=RSA,cn=encryption,cn=config"
Ensure that /etc/dirsrv/sladp-server/dse.ldif has appropriate directives for SSL/TLS to work smoothly:
[root@server]# egrep -i 'nsslapd-security|nsssl3|nssslclientauth|nssslpersonalityssl|nsSSLActivation' /etc/dirsrv/slapd-server/dse.ldif
nsslapd-security: on
nsSSLClientAuth: allowed
nsSSL3: on
nsSSL3Ciphers: -rsa_null_md5,+rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5,
nsSSLPersonalitySSL: Server-Cert-ldap
nsSSLActivation: on
Restart the Red Hat Directory Server instance (on a secure port):

NOTE

The PIN being prompted for below is merely referring to the password used throughout this test.
[root@server]# /sbin/service dirsrv restart
Shutting down dirsrv:
    server...                                            [  OK  ]
Starting dirsrv:
    server...Enter PIN for Internal (Software) Token:
                                                           [  OK  ]
Perform an LDAP search with SSL/TLS to ensure that everything is working smoothly:
[root@server]# /usr/lib64/mozldap/ldapsearch -h server.example.com -p 636 -Z -P /etc/dirsrv/slapd-server/cert8.db -D "cn=Directory Manager" -w Secret123 -b "cn=config" objectclass=* dn
version: 1
dn: cn=config

dn: cn=encryption,cn=config

dn: cn=features,cn=config

dn: cn=mapping tree,cn=config

.
.
.
Export the CA certificate from dirsrv into base-64 pem format:
[root@server]# /usr/bin/certutil -L -d /etc/dirsrv/slapd-server -n "LDAP Self Signed CA certificate" -a > ldap-ca.crt
Import the temporary LDAP self-signed CA certificate into the pki-ca's NSS security database with the appropriate trust attributes set:
[root@server]# /usr/bin/certutil -L -d /var/lib/pki-ca/alias

Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI

Server-Cert cert-pki-ca                                      CTu,Cu,Cu
[root@server]# /usr/bin/certutil -A -i ldap-ca.crt -t "CT,C,C" -d /var/lib/pki-ca/alias -n "LDAP Self Signed CA certificate"

Important

Configuring SSL between Red Hat Certificate System and Red Hat Directory Server won't work unless the appropriate trust attributes ('CT,C,C') are set.
List certificates in the pki-ca NSS security database after importing the LDAP Self Signed CA certificate:
[root@server]# /usr/bin/certutil -L -d /var/lib/pki-ca/alias/

Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI

Server-Cert cert-pki-ca                                      CTu,Cu,Cu
LDAP Self Signed CA certificate                              CT,C,C
Start the CA instance:
[root@server]# /sbin/service pki-ca start
Starting pki-ca:
    Using Java Security Manager
    Constructing 'pki-ca.policy' Security Policy
Starting pki-ca:                                           [  OK  ]

pki-ca (pid 26728) is running ...

    'pki-ca' must still be CONFIGURED!
    (see /var/log/pki-ca-install.log)
Clean up temporary files:
  • Move /tmp/db-backup.tar to a secure location, or delete it from the system:
    [root@server]# rm -f /tmp/db-backup.tar
    
  • Delete /tmp/example.ldif from the system:
    [root@server]# rm -f /tmp/example.ldif
    
  • Delete /tmp/pwdfile from the system:
    [root@server]# rm -f /tmp/pwdfile
    
B.2.1.5.3. Hardware Security Module CA Configuration
Follow instructions in the following procedural reference:
B.2.1.5.4. CA Instance Configuration

NOTE

This section involves configuring a CA instance using SSL with Directory Server
Since pkicreate has been executed in Section B.2.1.5.1, “CA Instance Creation”, obtain the URL to configure the CA by doing a tail /var/log/pki-ca-install.log:
[root@server]# tail /var/log/pki-ca-install.log
[2011-03-27 01:40:59] [debug] Restorecon file context for /etc/pki-ca/tomcat5.conf
[2011-03-27 01:40:59] [debug] Setting selinux context pki_ca_port_t for 9446
[2011-03-27 01:41:04] [debug] Setting 'pki-ca' runlevel to '-'
[2011-03-27 01:41:04] [debug] Setting 'pki-ca' start priority to '81'
[2011-03-27 01:41:04] [debug] Setting 'pki-ca' stop priority to '19'
[2011-03-27 01:41:04] [debug] Registered 'pki-ca' with '/sbin/chkconfig'.
[2011-03-27 01:41:14] [log] Configuration Wizard listening on
https://server.example.com:9445/ca/admin/console/config/login?pin=rci6U5OFSeuT92X3HbhG
[2011-03-27 01:41:14] [log] After configuration, the server can be operated by the command:
/sbin/service pki-ca start | stop | restart

Important

For configuration purposes, a Firefox browser must be used to configure all PKI subsystems.
As an administrator, launch a Firefox browser using the profile manager:
[root@server]# /usr/bin/firefox -ProfileManager -no-remote
Create a new profile entitled server:
  • Click Next>
  • Enter new profile name: server
  • Click Finish
Open the URL displayed in /var/log/pki-ca-install.log in the Firefox browser.
Within the Firefox browser, click on "I Understand the Risks" -> "Add Exception..." -> "Get Certificate" -> "Confirm security Exception".
Traverse the CA configuration panels:
  • Welcome panel:
    • Click Next>
  • Key Store panel:
    • Click on 'Login' for NHSM6000-OCS (nCipher's nFast Token Hardware Module)
    • Provide the 'Security Module Token Password'
    • Click Next>
    • Back in the Key Store panel, select the 'NHSM6000-OCS' Token
    • Click Next>
  • Security Domain panel:
    • Accept the defaults
    • Click Next>
  • Subsystem Type panel:
    • Accept the defaults
    • Click Next>
  • PKI Hierarchy panel:
    • Accept the defaults
    • Click Next>
  • Internal Database panel:
    • 'Host' -- server.example.com
    • 'Port' -- 636 (SSL port)
    • Check the 'SSL' box
    • Provide the 'Bind Password' of the 'Directory Manager' (value which you gave while creating a Red Hat Directory Server instance)
    • Click Next>
  • Key Pairs panel:
    • Accept the defaults.
    • Select the 'Use the default key size (2048 bits).' radio button
    • Click Next>
  • Subject Names panel:
    • Accept the defaults
    • Click Next>
  • Requests and Certificates panel:
    • Click on 'Apply'
    • Once the screen redraws, click on Next>

NOTE

It is not possible to export keys and certificates stored on an HSM to a .p12 file. It is also not necessary to extract keys from the HSM to clone a subsystem. The keys are already stored on the HSM and accessible to any cloned instances.
  • Export Keys and Certificates panel:
    • Accept the defaults.
    • Click Next>
  • Import CA's Certificate Chain panel:
    • Click OK for the prompt 'You will now be asked to import and trust the Certificate Chain from the CA. Please do so.'
    • Select the check-boxes for:
      • Check 'Trust this CA to identify web sites'
      • Check 'Trust this CA to identify email users'
      • Check 'Trust this CA to identify software developers'
      • Click OK to dismiss this dialog box
    • Click Next>
  • Administrator panel:
    • UID: admin
    • Name: CA Administrator of Instance pki-ca
    • Email: pki-ca-admin@example.com
    • Password:
    • Password (Again):
    • Click Next>
  • Import Administrator's Certificate panel:
    • Click OK on the alert which says'Your personal certificate has been installed. You should keep a backup copy of this certificate.'
    • Click Next>
  • Done panel:
    • Restart the CA by running /sbin/service pki-ca restart
Enabling FIPS Mode
Then, enable FIPS mode for the HSM.
  1. Set up the HSM, as described in Section 6.3.9.2, “Using Hardware Security Modules with Subsystems” and the vendor documentation.
  2. Install and configure the CA instance, as described in Section 7.6.2, “Setting up CAs”.
  3. Stop the CA instance. The instance must be stopped to protect the information stored in its security databases.
    service pki-ca stop
  4. Replace the SSL subsystem certificate. By default, the installation process puts the certificate on the hardware token, but it should be placed on the software FIPS token.
    1. Open the CA's security database directory.
      cd /var/lib/pki-ca/alias
    2. Using certutil, create a request for a new SSL server certificate.
      certutil -d . -R -s "CN=ca.example.com,OU=pki-ca,O=Example Domain pki-ca" -o sslfips.req -h "NSS Certificate DB" -a
    3. Restart the CA.
      service pki-ca start
    4. Open the end entities pages for the CA (https://server.example.com:9444/ca/ee/ca), and use the SSL Server Cert Profile to submit the request.
    5. Log into the agent pages (https://server.example.com:9443/ca/agent/ca), and approve the request.
    6. Copy the base 64-encoded certificate on the approval page and save it to a file, such as sslfips.cert.
    7. Stop the CA again.
      service pki-ca stop
    8. Check the CA's certificate database to see if an SSL server certificate is already listed.
      certutil -d /var/lib/pki-ca/alias -L
    9. If the certificate exists, then delete it.
      certutil -d /var/lib/pki-ca/alias -D -n "ServerCert nickname"
    10. Import the new SSL server certificate.
      certutil -d /var/lib/pki-ca/alias -A -t "u,u,u" -n "ServerCert ca.example.com - Example Domain pki-ca" -i sslfips.cert -a
    11. Edit the /var/lib/pki-ca/conf/serverCertNick.conf file to contain the nickname of the new certificate, such as ServerCert ca.example.com - Example Domain pki-ca.
    12. Edit the CS.cfg file to replace both references to the SSL server certificate nickname.
      vim /var/lib/pki-ca/conf/CS/cfg
      
      ca.cert.sslserver.nickname= ServerCert ca.example.com - Example Domain pki-ca
      ca.sslserver.nickname= ServerCert ca.example.com - Example Domain pki-ca
    13. In the CS.cfg file, add a line to verify signatures from the token. The value is the token name, which depends on the vendor and version of the HSM. For example, for a NetHSM token:
       ca.requestVerify.token=NHSM6000-OCS
    14. Edi the server.xml file to enable FIPS mode for each SSL-enabled connector. Set strictCiphters to true and add or set ssl3 to false.
      vim /var/lib/pki-ca/conf/server.xml
      
      <Connector name="Agent" port="9443" maxHttpHeaderSize="8192"
              ...
              ...
              sslOptions="ssl2=false,ssl3=false,tls=true"
              strictCiphers="true"
              ...
      >
    15. Enable FIPS mode in the NSS software database.
      modutil -dbdir /var/lib/pki-ca/alias -fips true
    16. Verify that FIPS mode has been enabled. The command will return the current FIPS status.
      modutil -dbdir /var/lib/pki-ca/alias modutil -dbdir . -chkfips true
          
      FIPS mode enabled.
    17. Start the CA.
      service pki-ca start
B.2.1.5.5. Directory Server SSL Server Authentication Configuration (Trusted)
Create a certificate signing request (csr) for 'Server-Cert-ldap' (ensure 'cn=server.example.com' [FQDN] with the same nickname 'Server-Cert-ldap'):
[root@server]# cd /etc/dirsrv/slapd-server/
[root@server]# /usr/bin/certutil -R -s "cn=server.example.com" -o Server-Cert-ldap.req -d . -n "Server-Cert-ldap" -a
Enter Password or Pin for "NSS Certificate DB":

A random seed must be generated that will be used in the
creation of your key.  One of the easiest ways to create a
random seed is to use the timing of keystrokes on a keyboard.

To begin, type keys on the keyboard until this progress meter
is full.  DO NOT USE THE AUTOREPEAT FUNCTION ON YOUR KEYBOARD!


Continue typing until the progress meter is full:

|************************************************************|

Finished.  Press enter to continue:


Generating key.  This may take a few moments...

[root@server]# cat /etc/dirsrv/slapd-server/Server-Cert-ldap.req

Certificate request generated by Netscape certutil
Phone: (not specified)

Common Name: server.example.com
Email: (not specified)
Organization: (not specified)
State: (not specified)
Country: (not specified)

-----BEGIN NEW CERTIFICATE REQUEST-----
MIIBZjCB0AIBADAnMSUwIwYDVQQDExxtZWF0cGllLmRzZGV2LnNqYy5yZWRoYXQu
Y29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDCiCR7kumfiUOzvkUYoD7w
1u0TFjwtCpc1CHaOUzGF7jqqHQ4v1asLbJlTMeFO6pqayQbIt0DhzmzhNcZueSP+
mEMgKq1pqo7rsGGt9JBaRYSJCE8sbCLih0oCOieeSrSplJIMuXY4a3mnZkKZrhiP
kmEsRYO7ahtf61bvHM/rdwIDAQABoAAwDQYJKoZIhvcNAQEFBQADgYEAuUMC4r1Y
8qBmf9//4OtY4n8dQ16460BMcgn5yQqTJ0fN0zZC1gydZo6P4ibm8txMBVcW/sVw
sUpGFmSc+APufeQUUUbG7c4I1Z2RD8YnhysBpMwasvU8W++D25YjfyGwHg8FYAgI
OYRTGzapYwo3mvSPd9GJYQXTWtQzXS2SJU0=
-----END NEW CERTIFICATE REQUEST-----
As an administrator, launch a Firefox browser using the profile manager:
[root@server]# /usr/bin/firefox -ProfileManager -no-remote
Select the profile entitled server that was utilized for configuration of the CA in Section B.2.1.5.4, “CA Instance Configuration”.
Select the URL that points to the Secure Admin Port of the previously configured CA and open the browser to a new tab called CA Services.

Note

This URL can be identified by running /sbin/service pki-ca status.
Select the URL called SSL End Users Services to open a new tab called CA End-Entity within the browser.
Select the profile entitled Manual Server Certificate Enrollment, and perform the following procedures:
  • Cut the certificate request contained in the file called /etc/dirsrv/slapd-server/Server-Cert-ldap.req and paste it into the area called 'Certificate Request' on the form:
    -----BEGIN NEW CERTIFICATE REQUEST-----
    MIIBZjCB0AIBADAnMSUwIwYDVQQDExxtZWF0cGllLmRzZGV2LnNqYy5yZWRoYXQu
    Y29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDCiCR7kumfiUOzvkUYoD7w
    1u0TFjwtCpc1CHaOUzGF7jqqHQ4v1asLbJlTMeFO6pqayQbIt0DhzmzhNcZueSP+
    mEMgKq1pqo7rsGGt9JBaRYSJCE8sbCLih0oCOieeSrSplJIMuXY4a3mnZkKZrhiP
    kmEsRYO7ahtf61bvHM/rdwIDAQABoAAwDQYJKoZIhvcNAQEFBQADgYEAuUMC4r1Y
    8qBmf9//4OtY4n8dQ16460BMcgn5yQqTJ0fN0zZC1gydZo6P4ibm8txMBVcW/sVw
    sUpGFmSc+APufeQUUUbG7c4I1Z2RD8YnhysBpMwasvU8W++D25YjfyGwHg8FYAgI
    OYRTGzapYwo3mvSPd9GJYQXTWtQzXS2SJU0=
    -----END NEW CERTIFICATE REQUEST-----
    

Note

The certificate request listed above is only an EXAMPLE of what the certificate request will look like. Do NOT use this EXAMPLE certificate request as a part of this test!
  • Press the Submit button
  • A page entitled Certificate Profile should appear noting a request ID.
Within the browser, click on the tab entitled CA Services, and select the URL called Agent Services to open a new tab called CA Agent.

Note

At this point, a certificate may be presented in a dialog box entitled 'User Identification Request' in order for the agent to confirm his/her identity. Select the proper certificate to present as identification, and accept this by clicking the OK button.
Select the browser tab labeled CA Agent, and perform the following tasks:
  • Click on List Requests
  • Click on Find
  • Click on the request id # of the entry labeled CN=server.example.com
  • Scroll to the bottom of this request, and click on the submit button to approve this request.
  • Scroll to the bottom of the approved request and highlight the Base-64 Encoded Certificate:
    -----BEGIN CERTIFICATE-----
    MIIDETCCAfmgAwIBAgIBBzANBgkqhkiG9w0BAQsFADBRMR4wHAYDVQQKExVEc2Rl
    dlNqY1JlZGhhdCBEb21haW4xDzANBgNVBAsTBnBraS1jYTEeMBwGA1UEAxMVQ2Vy
    dGlmaWNhdGUgQXV0aG9yaXR5MB4XDTExMDQwNTE0NTYwNFoXDTEzMDMyNTE0NTYw
    NFowJzElMCMGA1UEAxMcbWVhdHBpZS5kc2Rldi5zamMucmVkaGF0LmNvbTCBnzAN
    BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwogke5Lpn4lDs75FGKA+8NbtExY8LQqX
    NQh2jlMxhe46qh0OL9WrC2yZUzHhTuqamskGyLdA4c5s4TXGbnkj/phDICqtaaqO
    67BhrfSQWkWEiQhPLGwi4odKAjonnkq0qZSSDLl2OGt5p2ZCma4Yj5JhLEWDu2ob
    X+tW7xzP63cCAwEAAaOBoTCBnjAfBgNVHSMEGDAWgBSZf6S8So4MpJJ4y00tJUo2
    2pPsuTBMBggrBgEFBQcBAQRAMD4wPAYIKwYBBQUHMAGGMGh0dHA6Ly9tZWF0cGll
    LmRzZGV2LnNqYy5yZWRoYXQuY29tOjkxODAvY2Evb2NzcDAOBgNVHQ8BAf8EBAMC
    BPAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMA0GCSqGSIb3DQEBCwUA
    A4IBAQBBw349t89Jny3L1/Txf49cGXzmNG0s2Fi8tW/1XTP4RmcJhnifAGAmlViQ
    ZgHzYZ4VoBw9a5m4WyiXo1JZ3SfyqsKSqEAa6vGhFNTgN0XPQKzIKWcbIWZqX+/B
    SqPYwl4HYpf+BWtIRjCtP6Mxaold8CEiYzRaEYqbVIgmNluQ7kmH2rTS+r0OSOyH
    qZeJ1GGU/u6+/a4jKmx3bHyFWkdmcwWgnkwCLO8/xnIqhsaPL8Z4Wlw7OTMXEghp
    iZKzhLAkcs232sMNbCjsXabUo5+uvJy4+bYXTLoJoOBpWcs8141+B3GtUlW3xIPr
    U0jjGCnKgczztRf+/5Ut3wWWKNGB
    -----END CERTIFICATE-----
    

Note

The certificate listed above is only an EXAMPLE of what the certificate will look like. Do NOT use this EXAMPLE certificate as a part of this test!
  • Copy this highlighted 'Base-64 Encoded' certificate and paste it into a file called /etc/dirsrv/slapd-server/ldap-server-b64.crt.
  • Obtain the CA's signing certificate into a base-64-encoded pem format:
    [root@server]# /usr/bin/certutil -L -d /var/lib/pki-ca/alias/ -n "caSigningCert cert-pki-ca" -a > /etc/dirsrv/slapd-server/casigning-b64.crt
    
Stop the CA instance before modifying its NSS security databases:
[root@server]# /sbin/service pki-ca stop
Stopping pki-ca: ..                                        [  OK  ]
Stop the Red Hat Directory Server instance before modifying its NSS security databases:
[root@server]# /sbin/service dirsrv stop
Shutting down dirsrv:
    server...                                            [  OK  ]
Delete the temporary 'Server-Cert-ldap' certificate issued earlier in Section B.2.1.5.2, “Directory Server SSL Server Authentication Configuration (Temporary)”:
[root@server]# /usr/bin/certutil -L -d /etc/dirsrv/slapd-server

Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI

Server-Cert-ldap                                             u,u,u
LDAP Self Signed CA certificate                              CTu,u,u
[root@server]# /usr/bin/certutil -D -d /etc/dirsrv/slapd-server -n "Server-Cert-ldap"
[root@server]# /usr/bin/certutil -L -d /etc/dirsrv/slapd-server

Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI

LDAP Self Signed CA certificate                              CTu,u,u
Import the new trusted 'ldap-server-b64.crt' (issued by pki-ca) into the Red Hat Directory Server NSS security database:
[root@server]# /usr/bin/certutil -A -i ldap-server-b64.crt -d /etc/dirsrv/slapd-server -n "Server-Cert-ldap" -t "u,u,u"
[root@server]# /usr/bin/certutil -L -d /etc/dirsrv/slapd-server

Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI

Server-Cert-ldap                                             u,u,u
LDAP Self Signed CA certificate                              CTu,u,u
Delete the temporary LDAP self-signed CA certificate issued earlier in Section B.2.1.5.2, “Directory Server SSL Server Authentication Configuration (Temporary)”:
[root@server]# /usr/bin/certutil -D -d /etc/dirsrv/slapd-server -n "LDAP Self Signed CA certificate"
[root@server]# /usr/bin/certutil -L -d /etc/dirsrv/slapd-server

ertificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI

Server-Cert-ldap                                             u,u,u
Import the trusted CA signing certificate into the Red Hat Directory Server NSS security database and trust it:
[root@server]# /usr/bin/certutil -A -i casigning-b64.crt -d /etc/dirsrv/slapd-server -n "caSigningCert cert-pki-ca" -t "CTu,Cu,Cu"
[root@server]# /usr/bin/certutil -L -d /etc/dirsrv/slapd-server

Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI

Server-Cert-ldap                                             u,u,u
caSigningCert cert-pki-ca                                    CT,C,C
Delete the temporary LDAP self-signed CA certificate from the pki-ca's NSS security database:
[root@server]# /usr/bin/certutil -L -d /var/lib/pki-ca/alias

Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI

caSigningCert cert-pki-ca                                    CTu,Cu,Cu
Server-Cert cert-pki-ca                                      u,u,u
auditSigningCert cert-pki-ca                                 u,u,Pu
LDAP Self Signed CA certificate                              CT,C,C
ocspSigningCert cert-pki-ca                                  u,u,u
subsystemCert cert-pki-ca                                    u,u,u
[root@server]# /usr/bin/certutil -D -d /var/lib/pki-ca/alias -n "LDAP Self Signed CA certificate"
[root@server]# /usr/bin/certutil -L -d /var/lib/pki-ca/alias

Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI

caSigningCert cert-pki-ca                                    CTu,Cu,Cu
Server-Cert cert-pki-ca                                      u,u,u
auditSigningCert cert-pki-ca                                 u,u,Pu
ocspSigningCert cert-pki-ca                                  u,u,u
subsystemCert cert-pki-ca                                    u,u,u
Start the Red Hat Directory Server instance (on a secure port):

NOTE

The PIN being prompted for below is merely referring to the password used throughout this test.
[root@server]# /sbin/service dirsrv start
Starting dirsrv:
    server...Enter PIN for Internal (Software) Token:
                                                           [  OK  ]
Start the CA instance:
[root@server]# /sbin/service pki-ca start
Starting pki-ca:
    Using Java Security Manager
    Constructing 'pki-ca.policy' Security Policy
Please provide password for internal:
Please provide password for hardware-nethsm2k:
Please provide password for internaldb:
Please provide password for replicationdb:
Starting pki-ca:                                       [  OK  ]

pki-ca (pid 26828) is running ...

    Unsecure Port       = http://server.example.com:9180/ca/ee/ca
    Secure Agent Port   = https://server.example.com:9443/ca/agent/ca
    Secure EE Port      = https://server.example.com:9444/ca/ee/ca
    Secure Admin Port   = https://server.example.com:9445/ca/services
    EE Client Auth Port = https://server.example.com:9446/ca/eeca/ca
    PKI Console Port    = pkiconsole https://server.example.com:9445/ca
    Tomcat Port         = 9701 (for shutdown)

    PKI Instance Name:   pki-ca

    PKI Subsystem Type:  Root CA (Security Domain)

    Registered PKI Security Domain Information:
    ==========================================================================
    Name:  Example Domain
    URL:   https://server.example.com:9445
    ==========================================================================

B.2.1.6. DRM Instance Creation and Configuration

B.2.1.6.1. DRM Instance Creation
Use the pkicreate tool to create an Red Hat Certificate System 8.1 instance of a DRM.

Note

Make certain that the "-audit_group=pkiaudit" parameter is used.
Use the 'pkicreate' tool as shown below:
[root@server]# pkicreate -pki_instance_root=/var/lib        \
                           -pki_instance_name=pki-kra         \
                           -subsystem_type=kra                \
                           -agent_secure_port=10443           \
                           -ee_secure_port=10444              \
                           -admin_secure_port=10445           \
                           -unsecure_port=10180               \
                           -tomcat_server_port=10701          \
                           -user=pkiuser                      \
                           -group=pkiuser                     \
                           -audit_group=pkiaudit              \
                           -redirect conf=/etc/pki-kra        \
                           -redirect logs=/var/log/pki-kra    \
                           -verbose
B.2.1.6.2. Hardware Security Module DRM Configuration
Follow instructions in the following procedure (substituting the name 'pki-kra' for 'pki-ca'):
To enable FIPS mode, open the security UI:
/opt/nfast/bin/ksafe
In the 'Security World' tab, make sure that "Strict FIPS 140-2 Level III" is set to 'yes'.
For configuring FIPS mode, see the hardware vendor documentation.
B.2.1.6.3. DRM Instance Configuration

NOTE

This section involves configuring a DRM instance using SSL with Directory Server
Since pkicreate has been executed in Section B.2.1.6.1, “DRM Instance Creation”, obtain the URL to configure the DRM by doing a tail /var/log/pki-kra-install.log:
[root@server]# tail /var/log/pki-kra-install.log
[2011-03-27 07:46:37] [debug] Restorecon /etc/pki-kra
[2011-03-27 07:46:37] [debug] Restorecon file context for /etc/pki-kra/tomcat5.conf
[2011-03-27 07:46:37] [debug] Setting 'pki-kra' runlevel to '-'
[2011-03-27 07:46:37] [debug] Setting 'pki-kra' start priority to '82'
[2011-03-27 07:46:37] [debug] Setting 'pki-kra' stop priority to '18'
[2011-03-27 07:46:37] [debug] Registered 'pki-kra' with '/sbin/chkconfig'.
[2011-03-27 07:46:47] [log] Configuration Wizard listening on
https://server.example.com:10445/kra/admin/console/config/login?pin=QChOc9RPvMntinwq0YIV
[2011-03-27 07:46:47] [log] After configuration, the server can be operated by the command:
/sbin/service pki-kra start | stop | restart
As an administrator, launch a Firefox browser using the profile manager:
[root@server]# /usr/bin/firefox -ProfileManager -no-remote
Select the profile entitled server that was utilized for configuration of the CA in Section B.2.1.5.4, “CA Instance Configuration”.
Open the URL displayed in /var/log/pki-kra-install.log in the Firefox browser.
Within the Firefox browser, click on "I Understand the Risks" -> "Add Exception..." -> "Get Certificate" -> "Confirm security Exception".
Traverse the DRM configuration panels:
  • Welcome panel:
    • Click Next>
  • Key Store panel:
    • Click on 'Login' for NHSM6000-OCS (nCipher's nFast Token Hardware Module)
    • Provide the 'Security Module Token Password'
    • Click Next>
    • Back in the Key Store panel, select the 'NHSM6000-OCS' Token
    • Click Next>
  • Security Domain panel:
    • Select 'Join an Existing Security Domain' and enter the URL to an existing security domain. This URL can be identified by running /sbin/service pki-ca status.
    • Click Next>
  • Display Certificate Chain panel:
    • Click Next>
  • Security Domain Login panel:
    • Supply the admin uid name and password for the CA so that it can be properly accessed.
    • Click Login
  • Subsystem Type panel:
    • Accept the defaults.
    • Click Next>
  • Internal Database panel:
    • 'Host' -- server.example.com
    • 'Port' -- 636 (SSL port)
    • Check the 'SSL' box
    • Provide the 'Bind Password' of the 'Directory Manager' (value which you gave while creating a Red Hat Directory Server instance)
    • Click Next>
  • Key Pairs panel:
    • Accept the defaults.
    • Select the 'Use the default key size (2048 bits).' radio button
    • Click Next>
  • Subject Names panel:
    • Accept the defaults
    • Click Next>
  • Requests and Certificates panel:
    • Click on 'Apply'
    • Once the screen redraws, click on Next>

NOTE

It is not possible to export keys and certificates stored on an HSM to a .p12 file. It is also not necessary to extract keys from the HSM to clone a subsystem. The keys are already stored on the HSM and accessible to any cloned instances.
  • Export Keys and Certificates panel:
    • Accept the defaults.
    • Click Next>
  • Administrator panel:
    • UID: admin
    • Name: KRA Administrator of Instance pki-kra
    • Email: pki-kra-admin@example.com
    • Password:
    • Password (Again):
    • Click Next>
  • Import Administrator's Certificate panel:
    • Click OK on the alert which says'Your personal certificate has been installed. You should keep a backup copy of this certificate.'
    • Click Next>
  • Done panel:
    • Stop the DRM by running /sbin/service pki-kra stop.
Enabling FIPS Mode
Then, enable FIPS mode for the HSM.
  1. Set up the HSM, as described in Section 6.3.9.2, “Using Hardware Security Modules with Subsystems” and the vendor documentation.
  2. Install and configure the instance, as described in Section 7.6.4, “Setting up DRMs, OCSPs, and TKSs”.
  3. Stop the instance. The instance must be stopped to protect the information stored in its security databases.
    service instance_name stop
  4. Replace the SSL subsystem certificate. By default, the installation process puts the certificate on the hardware token, but it should be placed on the software FIPS token.
    1. Open the instance's security database directory.
      cd /var/lib/instance_name/alias
    2. Using certutil, create a request for a new SSL server certificate.
      certutil -d . -R -s "CN=server.example.com,OU=instance_name,O=Example Domain instance_name" -o sslfips.req -h "NSS Certificate DB" -a
    3. Open the end entities pages for the CA (https://server.example.com:9444/ca/ee/ca), and use the SSL Server Cert Profile to submit the request.
    4. Log into the agent pages (https://server.example.com:9443/ca/agent/ca), and approve the request.
    5. Copy the base 64-encoded certificate on the approval page and save it to a file, such as sslfips.cert.
    6. Check the instance's certificate database to see if an SSL server certificate is already listed.
      certutil -d /var/lib/instance_name/alias -L
    7. If the certificate exists, then delete it.
      certutil -d /var/lib/instance_name/alias -D -n "ServerCert nickname"
    8. Import the new SSL server certificate.
      certutil -d /var/lib/instance_name/alias -A -t "u,u,u" -n "ServerCert server.example.com - Example Domain instance_name" -i sslfips.cert -a
    9. Edit the /var/lib/instance_name/conf/serverCertNick.conf file to contain the nickname of the new certificate, such as ServerCert server.example.com - Example Domain instance_name.
    10. Edit the CS.cfg file to replace both references to the SSL server certificate nickname.
      vim /var/lib/instance_name/conf/CS/cfg
      
      type.cert.sslserver.nickname= ServerCert server.example.com - Example Domain instance_name
      type.sslserver.nickname= ServerCert server.example.com - Example Domain instance_name
    11. Edit the server.xml file to enable FIPS mode for each SSL-enabled connector. Set strictCiphters to true and add or set ssl3 to false. For example:
      vim /var/lib/instance_name/conf/server.xml
      
      <Connector name="Agent" port="10443" maxHttpHeaderSize="8192"
              ...
              ...
              sslOptions="ssl2=false,ssl3=false,tls=true"
              strictCiphers="true"
              ...
      >
    12. Enable FIPS mode in the NSS software database.
      modutil -dbdir /var/lib/instance_name/alias -fips true
    13. Verify that FIPS mode has been enabled. The command will return the current FIPS status.
      modutil -dbdir /var/lib/instance_name/alias modutil -dbdir . -chkfips true
          
      FIPS mode enabled.
    14. Start the instance.
      service instance_name start

B.2.1.7. OCSP Instance Creation and Configuration

B.2.1.7.1. OCSP Instance Creation
Use the pkicreate tool to create an Red Hat Certificate System 8.1 instance of an OCSP Responder.

Note

Make certain that the "-audit_group=pkiaudit" parameter is used.
Use the 'pkicreate' tool as shown below:
[root@server]# pkicreate -pki_instance_root=/var/lib        \
                           -pki_instance_name=pki-ocsp        \
                           -subsystem_type=ocsp               \
                           -agent_secure_port=11443           \
                           -ee_secure_port=11444              \
                           -admin_secure_port=11445           \
                           -unsecure_port=11180               \
                           -tomcat_server_port=11701          \
                           -user=pkiuser                      \
                           -group=pkiuser                     \
                           -audit_group=pkiaudit              \
                           -redirect conf=/etc/pki-ocsp       \
                           -redirect logs=/var/log/pki-ocsp   \
                           -verbose
B.2.1.7.2. Hardware Security Module OCSP Configuration
Follow instructions in the following procedural reference (substituting the name 'pki-ocsp' for 'pki-ca'):
B.2.1.7.3. OCSP Instance Configuration

NOTE

This section involves configuring an OCSP instance using SSL with Directory Server
Since pkicreate has been executed in Section B.2.1.7.1, “OCSP Instance Creation”, obtain the URL to configure the OCSP Responder by doing a tail /var/log/pki-ocsp-install.log:
[root@server]# tail /var/log/pki-ocsp-install.log
[2011-03-27 07:22:03] [debug] Restorecon /etc/pki-ocsp
[2011-03-27 07:22:03] [debug] Restorecon file context for /etc/pki-ocsp/tomcat5.conf
[2011-03-27 07:22:04] [debug] Setting 'pki-ocsp' runlevel to '-'
[2011-03-27 07:22:04] [debug] Setting 'pki-ocsp' start priority to '83'
[2011-03-27 07:22:04] [debug] Setting 'pki-ocsp' stop priority to '17'
[2011-03-27 07:22:04] [debug] Registered 'pki-ocsp' with '/sbin/chkconfig'.
[2011-03-27 07:22:13] [log] Configuration Wizard listening on
https://server.example.com:11445/ocsp/admin/console/config/login?pin=xpjt2dv5zbjrdafGTaqT
[2011-03-27 07:22:13] [log] After configuration, the server can be operated by the command:
/sbin/service pki-ocsp start | stop | restart
As an administrator, launch a Firefox browser using the profile manager:
[root@server]# /usr/bin/firefox -ProfileManager -no-remote
Select the profile entitled server that was utilized for configuration of the CA in Section B.2.1.5.4, “CA Instance Configuration”.
Open the URL displayed in /var/log/pki-ocsp-install.log in the Firefox browser.
Within the Firefox browser, click on "I Understand the Risks" -> "Add Exception..." -> "Get Certificate" -> "Confirm security Exception".
Traverse the OCSP configuration panels:
  • Welcome panel:
    • Click Next>
  • Key Store panel:
    • Click on 'Login' for NHSM6000-OCS (nCipher's nFast Token Hardware Module)
    • Provide the 'Security Module Token Password'
    • Click Next>
    • Back in the Key Store panel, select the 'NHSM6000-OCS' Token
    • Click Next>
  • Security Domain panel:
    • Select 'Join an Existing Security Domain' and enter the URL to an existing security domain. This URL can be identified by running /sbin/service pki-ca status.
    • Click Next>
  • Display Certificate Chain panel:
    • Click Next>
  • Security Domain Login panel:
    • Supply the admin uid name and password for the CA so that it can be properly accessed.
    • Click Login
  • Subsystem Type panel:
    • Accept the defaults.
    • Click Next>
  • Internal Database panel:
    • 'Host' -- server.example.com
    • 'Port' -- 636 (SSL port)
    • Check the 'SSL' box
    • Provide the 'Bind Password' of the 'Directory Manager' (value which you gave while creating a Red Hat Directory Server instance)
    • Click Next>
  • Key Pairs panel:
    • Accept the defaults.
    • Select the 'Use the default key size (2048 bits).' radio button
    • Click Next>
  • Subject Names panel:
    • Accept the defaults
    • Click Next>
  • Requests and Certificates panel:
    • Click on 'Apply'
    • Once the screen redraws, click on Next>

NOTE

It is not possible to export keys and certificates stored on an HSM to a .p12 file. It is also not necessary to extract keys from the HSM to clone a subsystem. The keys are already stored on the HSM and accessible to any cloned instances.
  • Export Keys and Certificates panel:
    • Accept the defaults.
    • Click Next>
  • Administrator panel:
    • UID: admin
    • Name: OCSP Administrator of Instance pki-ocsp
    • Email: pki-ocsp-admin@example.com
    • Password:
    • Password (Again):
    • Click Next>
  • Import Administrator's Certificate panel:
    • Click OK on the alert which says'Your personal certificate has been installed. You should keep a backup copy of this certificate.'
    • Click Next>
  • Done panel:
    • Stop the OCSP Responder by running /sbin/service pki-ocsp stop.
Enabling FIPS Mode
Then, enable FIPS mode for the HSM.
  1. Set up the HSM, as described in Section 6.3.9.2, “Using Hardware Security Modules with Subsystems” and the vendor documentation.
  2. Install and configure the instance, as described in Section 7.6.4, “Setting up DRMs, OCSPs, and TKSs”.
  3. Stop the instance. The instance must be stopped to protect the information stored in its security databases.
    service instance_name stop
  4. Replace the SSL subsystem certificate. By default, the installation process puts the certificate on the hardware token, but it should be placed on the software FIPS token.
    1. Open the instance's security database directory.
      cd /var/lib/instance_name/alias
    2. Using certutil, create a request for a new SSL server certificate.
      certutil -d . -R -s "CN=server.example.com,OU=instance_name,O=Example Domain instance_name" -o sslfips.req -h "NSS Certificate DB" -a
    3. Open the end entities pages for the CA (https://server.example.com:9444/ca/ee/ca), and use the SSL Server Cert Profile to submit the request.
    4. Log into the agent pages (https://server.example.com:9443/ca/agent/ca), and approve the request.
    5. Copy the base 64-encoded certificate on the approval page and save it to a file, such as sslfips.cert.
    6. Check the instance's certificate database to see if an SSL server certificate is already listed.
      certutil -d /var/lib/instance_name/alias -L
    7. If the certificate exists, then delete it.
      certutil -d /var/lib/instance_name/alias -D -n "ServerCert nickname"
    8. Import the new SSL server certificate.
      certutil -d /var/lib/instance_name/alias -A -t "u,u,u" -n "ServerCert server.example.com - Example Domain instance_name" -i sslfips.cert -a
    9. Edit the /var/lib/instance_name/conf/serverCertNick.conf file to contain the nickname of the new certificate, such as ServerCert server.example.com - Example Domain instance_name.
    10. Edit the CS.cfg file to replace both references to the SSL server certificate nickname.
      vim /var/lib/instance_name/conf/CS/cfg
      
      type.cert.sslserver.nickname= ServerCert server.example.com - Example Domain instance_name
      type.sslserver.nickname= ServerCert server.example.com - Example Domain instance_name
    11. Edit the server.xml file to enable FIPS mode for each SSL-enabled connector. Set strictCiphters to true and add or set ssl3 to false. For example:
      vim /var/lib/instance_name/conf/server.xml
      
      <Connector name="Agent" port="11443" maxHttpHeaderSize="8192"
              ...
              ...
              sslOptions="ssl2=false,ssl3=false,tls=true"
              strictCiphers="true"
              ...
      >
    12. Enable FIPS mode in the NSS software database.
      modutil -dbdir /var/lib/instance_name/alias -fips true
    13. Verify that FIPS mode has been enabled. The command will return the current FIPS status.
      modutil -dbdir /var/lib/instance_name/alias modutil -dbdir . -chkfips true
          
      FIPS mode enabled.
    14. Start the instance.
      service instance_name start

B.2.1.8. Post Configuration Instructions

B.2.1.8.1. Agent, Administrator, and Audit User Creation
The setup process only creates a single administrative user account. To manage a PKI environment in real life requires a larger number of administrators, agents, and auditors which are created after the instance is set up.
Log into server.example.com as an administrator, and launch the Console to create the users:
[root@server]# /usr/bin/pkiconsole https://server.example.com:9445/ca
These users are to be created as appropriate for relevant CS subsystems including CA, DRM, and OCSP.
  • For Admin users:
    • adminV (this user will have a valid certificate throughout testing)
    • adminR (this user will have a revoked certificate)
    • adminE (this user will have an expired certificate)
    • adminTCA (this user's certificate will be signed by a trusted CA)
    • adminC (initially this user will be assigned to the administrator group; during the testing process this user will be assigned to a different group)
    • adminUTCA (this user's certificate will be issued by an untrusted CA) [Note: This requires a second CA setup!]
  • For Agent users:
    • agentV (this user will have a valid certificate throughout testing)
    • agentR (the status of this user's certificate is Revoked)
    • agentE (this user's certificate is in the expired state)
    • adminTCA (this user's certificate will be signed by a trusted CA)
    • agentTCA (this user's certificate will be issued by a trusted CA))
    • agentUTCA (this user's certificate will be issued by an untrusted CA) [Note: This requires a second CA setup!]
  • For Audit users:
    • auditV (this user will have a valid certificate throughout testing)
  • To Revoke Certificates
  • To Achieve Expired Certificates

    Expired Certificates

    From CA EE pages, submit enrollment requests for all of these users.
     
    From the CA Agent port, approve these requests. When approving expired certs, remember to change 'notAfter' to point to 1-day.
B.2.1.8.2. Import of Certificate Chain into Browser
Any browser which will be used to access agent or admin services pages must have the client certificate and the CA certificate chain imported into its trust store.

Note

Since this test uses a common browser profile for its CA, DRM, and OCSP instances, the following steps will NOT be necessary as the certificate chain was imported during creation of the CA as documented in Section B.2.1.5.4, “CA Instance Configuration”. However, if different browser profiles had been used for its DRM and OCSP instances, the following steps would have been necessary.
To import the certificate chain into the browser, perform the following steps:
  • Select the URL that points to the Secure End-Entity Port of the previously configured CA and open the browser to this URL.

Note

This URL can be identified by running /sbin/service pki-ca status.
  • Click on the tab labeled Retrieval
  • Select the URL called Import CA Certificate Chain
  • Select the radio button for Import the CA certificate chain into your browser
  • Click on the submit button.
  • Click OK for the prompt 'You will now be asked to import and trust the Certificate Chain from the CA. Please do so.'
  • Select the check-boxes for:
    • Check 'Trust this CA to identify web sites'
    • Check 'Trust this CA to identify email users'
    • Check 'Trust this CA to identify software developers'
    • Click OK to dismiss this dialog box
B.2.1.8.3. Sudo Permissions for PKI Services
Granting sudo permissions for Certificate System and Directory Server services to PKI administrators makes it easier to manage the instances.
To grant these sudo permissions, execute the following command:
[root@server]# /usr/sbin/visudo
Add the following lines to the /etc/sudoers file:
# For Directory Server services
%pkiadmin ALL = PASSWD: /sbin/service dirsrv *
%pkiadmin ALL = PASSWD: /sbin/service dirsrv-admin *

# For PKI instance management
%pkiadmin ALL = PASSWD: /usr/bin/pkicreate *
%pkiadmin ALL = PASSWD: /usr/bin/pkiremove *

# For PKI instance services
%pkiadmin ALL = PASSWD: /sbin/service pki-ca *
%pkiadmin ALL = PASSWD: /sbin/service pki-kra *
%pkiadmin ALL = PASSWD: /sbin/service pki-ocsp *
B.2.1.8.4. Backup and Restore Procedures
A reliable backup and restore strategy is vital for disaster and data recovery.

Note

For the purposes of this test, no backup and recovery mechanism will be utilized.
B.2.1.8.5. Signed Audit
This can be done when an instance is first created by using the -audit_group option, but it can also be done post-installation.
The following procedural reference can be followed to enable signed auditing:
Procedural Reference: Managing Signed Audit Logs
B.2.1.8.6. Revocation Checking and OCSP Responders
There are two methods for checking whether a certificate is active (and not revoked): CRL checking and OCSP services. Checking the revocation status helps ensure that a revoked certificate isn't wrongly accepted just because it is within its validity period.
The following procedural reference can be followed to enable revocation checking:
Procedural Reference: Enabling Revocation Checking
Similarly, the following procedural reference can be followed to establish an OCSP responder:
B.2.1.8.7. SSL Session Timeouts
Using session timeouts prevents unauthorized users from accessing an open, but otherwise inactive, session with a subsystem.

Note

For the purposes of this test, the default SSL Session Timeouts for the CA, DRM, and OCSP instances should be sufficient.
To alter the default behavior of this feature, follow the procedural reference below applying it to the CA, DRM, and OCSP instances:
Procedural Reference: Setting SSL Session Timeouts
B.2.1.8.8. Self-Tests Execution
Self-tests are subsystem type-specific diagnostics. These are usually run when the server starts, but they can also be run on demand. Additionally, self-test can be customized by creating new self-test plug-ins or to accommodate changes to the subsystem configuration like new certificates or changed certificate nicknames.

Note

For the purposes of this test, all required instance-specific self-tests were automatically registered and configured when each instance was installed.
Optional Reference: Running Self-Tests
B.2.1.8.9. Removal of password.conf
The password.conf file stores system passwords in plaintext.
Remove the /var/lib/pki-ca/password.conf file to 'prompt for passwords', restart the pki-ca server, and provide the passwords prompted. The following example is for the CA.

Important

Similar changes need to be done for all other PKI subsystem instances!
[root@server]# pwd
/var/lib/pki-ca/conf

[root@server]# rm -rf password.conf

[root@server]# /sbin/service pki-ca restart
Stopping pki-ca: ..                                    [  OK  ]
Starting pki-ca:
    Using Java Security Manager
    Constructing 'pki-ca.policy' Security Policy
Please provide password for internal:
Please provide password for hardware-nethsm2k:
Please provide password for internaldb:
Please provide password for replicationdb:
Starting pki-ca:                                       [  OK  ]

pki-ca (pid 26928) is running ...

    Unsecure Port       = http://server.example.com:9180/ca/ee/ca
    Secure Agent Port   = https://server.example.com:9443/ca/agent/ca
    Secure EE Port      = https://server.example.com:9444/ca/ee/ca
    Secure Admin Port   = https://server.example.com:9445/ca/services
    EE Client Auth Port = https://server.example.com:9446/ca/eeca/ca
    PKI Console Port    = pkiconsole https://server.example.com:9445/ca
    Tomcat Port         = 9701 (for shutdown)

    PKI Instance Name:   pki-ca

    PKI Subsystem Type:  Root CA (Security Domain)

    Registered PKI Security Domain Information:
    ==========================================================================
    Name:  Example Domain
    URL:   https://server.example.com:9445
    ==========================================================================

Note

Apply this same process to both the DRM and OCSP instances.
Optional Reference: System Passwords
B.2.1.8.10. Removal of Unused Interfaces from web.xml
Several legacy interfaces are included in the CA's web.xml. While these can be used for custom or legacy applications to connect to the CA, for secure environments, these deprecated interfaces should be removed from the CA configuration to prevent unauthorized access.
To perform this step, please refer to the following procedural reference:
B.2.1.8.11. Downloading dumpans1 tool
Download dumpasn1 from the url below; compile it with gcc; then copy it to /usr/local/bin:
[root@server]# wget http://www.cs.auckland.ac.nz/~pgut001/dumpasn1.c
[root@server]# /usr/bin/gcc -o dumpasn1 dumpasn1.c 
[root@server]# cp dumpasn1 /usr/local/bin/
B.2.1.8.12. Disable User/Group "multiroles" Support for Java Subsystems
By the default, the Certificate System Console for Java Subsystems supports the notion of allowing given users the ability to reside within more than one group at a time. Ultimately this property makes it possible for a single user to assume more than one distinct role. This default behavior is fine for normal processing. The CC setup requires that we configure the systems to not allow this multirole behavior.
For CA, KRA, TKS, and OCSP subystems:
  1. Stop the server:
    service pki-ca stop
  2. Open the CS.cfg file:
    vim /var/lib/pki-ca/conf/CS.cfg
  3. Modify the current setting of multiroles.enable=true and change it to multiroles.enable=false.
  4. Restart the server:
    service pki-ca restart
B.2.1.8.13. Configuring POSIX System ACLs
POSIX system access control rules provide finer granularity over system user permissions. These ACLs must be set for each instance after it is fully configured.
Steps 3 and 4 only need to be performed once. The rest of the procedure must be performed separately for every instance installed on the machine.
  1. Log into the system as root.
  2. Stop all Certificate System subsystems.
    service instance_name stop
  3. Make sure that the acl package is installed on the system.
    # rpm -q acl
    acl-2.2.39-6.el5
  4. Four filesystem paths must be configured to use the acl package:
    • /
    • /etc (including /etc/init.d and /etc/sysconfig)
    • /usr (including /usr/bin and /usr/share)
    • /var (including /var/lock and /var/run)
    First, check to see where the filesystems are mounted and whether the acl option is used:
    # mount
    /dev/sda1 on / type ext3 (rw)
    proc on /proc type proc (rw)
    sysfs on /sys type sysfs (rw)
    devpts on /dev/pts type devpts (rw,gid=5,mode=620)
    /dev/sdb1 on /usr type ext2 (rw)
    tmpfs on /dev/shm type tmpfs (rw)
    none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
    sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
    In this example, /, /etc, and /var are mounted on /dev/sda1, while /usr is mounted on /dev/sdb1.
    There are two ways to apply the acl option to the filesystems:
    • Using tune2fs:
       # /sbin/tune2fs -o +acl /dev/sda1
      # /sbin/tune2fs -o +acl /dev/sdb1
    • Editing the /etc/fstab file:
      # vim /etc/fstab
      LABEL=/           /             ext3    defaults,acl    1 1
      LABEL=/usr        /usr          ext2    defaults,acl    1 2
      tmpfs             /dev/shm      tmpfs   defaults        0 0
      devpts            /dev/pts      devpts  gid=5,mode=620  0 0
      sysfs             /sys          sysfs   defaults        0 0
      proc              /proc         proc    defaults        0 0
      LABEL=SWAP-sdb2   swap          swap    defaults        0 0
      LABEL=SWAP-sda2   swap          swap    defaults        0 0
    Then, remount the filesystems.
    # mount -o remount /
    # mount -o remount /usr
    Confirm that the acl option has been applied to the filesystems:
    # /sbin/dumpe2fs /dev/sda1 | grep acl
    dumpe2fs 1.39 (29-May-2006)
    Default mount options:    user_xattr acl
    
    # /sbin/dumpe2fs /dev/sdb1 | grep acl
    dumpe2fs 1.39 (29-May-2006)
    Default mount options:    acl
    
    # mount | grep acl
    /dev/sda1 on / type ext3 (rw,acl)
    /dev/sdb1 on /usr type ext2 (rw,acl)
  5. Stop the instance.
    service instance_name stop
  6. Set the group readability to the pkiadmin group for the instance's directories and files.
    # setfacl -R -L -m g:pkiadmin:r,d:g:pkiadmin:r /var/lib/instance_name
  7. Apply execute (x) ACL permissions on all directories:
    # find -L /var/lib/instance_name -type d -exec setfacl -L -n -m g:pkiadmin:rx,d:g:pkiadmin:rx {} \;
  8. Remove group readability for the pkiadmin group from the instance's signedAudit/ directory and its associated files:
    # setfacl -R -L -x g:pkiadmin,d:g:pkiadmin /var/lib/instance_name/logs/signedAudit
  9. Set group readability for the pkiaudit group for the instance's signedAudit/ directory and its associated files:
    # setfacl -R -L -m g:pkiaudit:r,d:g:pkiaudit:r /var/lib/instance_name/logs/signedAudit
  10. Re-apply execute (x) ACL permissions on the signedAudit/ directory and all of its subdirectories:
    # find -L /var/lib/instance_name/logs/signedAudit -type d -exec setfacl -L -n -m g:pkiaudit:rx,d:g:pkiaudit:rx {} \;
  11. Start the instance.
    service instance_name start
  12. Confirm that the file access controls were properly applied by using the getfacl command to show the current ACL settings:
    # getfacl /var/lib/instance_name /var/lib/instance_name/logs/signedAudit/
    getfacl: Removing leading '/' from absolute path names
    # file: var/lib/instance_name
    # owner: pkiuser
    # group: pkiuser
    user::rwx
    group::rwx
    group:pkiadmin:r-x
    mask::rwx
    other::r-x
    default:user::rwx
    default:group::rwx
    default:group:pkiadmin:r-x
    default:mask::rwx
    default:other::r-x
    
    # file: var/lib/instance_name/logs/signedAudit
    # owner: pkiuser
    # group: pkiaudit
    user::rwx
    group::rwx
    group:pkiaudit:r-x
    mask::rwx
    other::---
    default:user::rwx
    default:group::rwx
    default:group:pkiaudit:r-x
    default:mask::rwx
    default:other::---