6.2. Basic Installation

There are three major steps to be taken when setting up Certificate System. The first (covered in Chapter 5, Prerequisites and Preparation for Installation) goes through setting up the machine and the environment that will host the subsystem instance — making sure that the platform meets requirements, installing necessary applications and packages, and setting up the operating system. The next step involves creating and configuring the subsystem instance itself. The last step involves customizing the instance by setting up recommended features (Chapter 15, After Configuration: Checklist of Configuration Areas for Deploying Certificate System).
This walk-through simply shows, at a very high level, the major steps for setting up a functional PKI. The exact configuration, like what subsystem types are installed and the desired post-installation configuration, are dependent on the specific PKI design that you developed as part of planning your Certificate System deployment.
  1. Install a Red Hat Directory Server, as described in Section 5.3.3, “Installing Red Hat Directory Server”. This can be on a different machine from the Certificate System, which is the recommended scenario for most deployments.
  2. Create new, specific operating system groups for the Certificate System subsystems to run as. This is described in Section 5.3.7.1, “Creating Operating System Groups”.
  3. Assign users to the operating system groups to perform the subsystem administrative tasks. This is described in Section 5.3.7.2.3, “Associating Existing User Accounts with PKI Groups”.
  4. Download the Certificate System packages from the Red Hat Network channel.
  5. Install the packages.
  6. Run pkicreate to create the subsystem instances.
  7. Configure the Certificate System CA subsystem. At least one CA subsystem must be installed and fully configured before any other type of subsystem can be configured.
  8. Configure the RA, OCSP, and DRM subsystems. Once the CA is installed, the other subsystems can be installed and configured in any order.

6.2.1. Installing and Configuring a CA

  1. Set up the required yum repositories.
    1. Log into the Customer Portal.
    2. Open the Downloads tab, and click the Downloads box in the main window.
    3. Under any product group, click the Download Software button.
    4. Search for the product name Certificate System or select the Red Hat Certificate System product from the drop-down menu.
    5. Click the link for the appropriate architecture.
    6. On the Downloads tab for the Certificate System release, click the Binary Disc link and save the ISO image to media.
    7. On the machine which hosts the repository, if necessary, install the VSFTP daemon. For example: 
      [root@server ~]# yum install vsftpd
    8. On the machine which hosts the repository, mount the media with the ISO. For example: 
      [root@server ~]# mount /dev/cdrom /mnt
    9. On the machine which hosts the repository, create a directory for the Certificate System packages. 
      [root@server ~]# mkdir /var/pub/rhcsrepo
    10. Copy the Certificate System ISO into the new repository directory.
    11. Create the yum repository, pointing to the RPM directory in the ISO. 
      [root@server ~]# createrepo -g /var/pub/rhcsrepo/RedHat/RPMS
    12. Start the vsftpd service. 
      [root@server ~]# service vsftpd start
[root@server ~]# chkconfig vsftpd on
    13. On each client machine, create a .repo file with the repository information. For example: 
      [root@client ~]# touch /etc/yum.repos.d/rhcs.repo
[root@client ~]# vim /etc/yum.repos.d/rhcs.repo

[rhcs]
 name=rhcs
 baseurl=ftp://repo_ip_address/pub/rhcsrepo 
 enabled=1
 gpgcheck=0
  2. To use an IPv6 hostname for configuration, set the hostname in the PKI_HOSTNAME environment variable before installing the packages. This is described in Section 12.3, “Enabling IPv6 for a Subsystem”.
  3. Run yum to install the CA packages. Optionally, include the console packages. 
    [root@server ~]# yum install pki-ca pki-console
  4. Run the pkicreate command to create the CA instance. For example: 
    [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
	  -audit_group=pkiaudit
	  -redirect logs=/var/log/pki-name/logs

PKI instance creation Utility ...


PKI instance creation completed ...

Starting instance_name:                                     [  OK  ]

instance_name (pid 17990) is running ...

    'instance_name' must still be CONFIGURED!
    (see /var/log/pki-name-install.log)

Before proceeding with the configuration, make sure
the firewall settings of this machine permit proper
access to this subsystem.

Please start the configuration by accessing:

http://server.example.com:9180/ca/admin/console/config/login?pin=kI7E1MByNIUcPJ6RKHmH

After configuration, the server can be operated by the command:

    service instance_name start | stop | restart
    This example uses the recommended port separation configuration, specifies an auditor group, and uses a Java Security Manager. Other options could be specified to set user-defined log and configuration directories and a user-defined operating system user and group. For other pkicreate options, see Table 6.1, “pkicreate Parameters”.
    The command options here are on separate lines to make it clear what options are used. All options should be on a single line.
  5. Create a new Firefox browser profile to use for configuring and accessing subsystems. Because of the certificates that are loaded, it is simpler and cleaner to use a fresh profile.
  6. When the pkicreate command completes, it returns a URL to use to access the web-based configuration wizard and a PIN to use to authenticate. Open the configuration wizard using the URL returned from the package installation.
    Alternatively, log into the setup wizard through the admin link on the services page and supply the preop.pin value from the /var/lib/pki-ca/conf/CS.cfg file when prompted. 
    https://server.example.com:9444/ca/services
  7. Select the token which will store the Certificate System certificates and keys; a list of detected hardware tokens and databases is given.
    Any hardware tokens used with the instance must be configured before configuring the subsystem instance.
    The Certificate System automatically discovers Safenet's LunaSA and nCipher's netHSM hardware security modules. The discovery process assumes that the client software installations for these modules are local to the Certificate System subsystem and are in the following locations:
    • LunaSA: /usr/lunasa/lib/libCryptoki2.so
    • LunaSA: /usr/lunasa/lib/libCryptoki2_64.so
    • nCipher: /opt/nfast/toolkits/pkcs11/libcknfast.so
  8. Create a new security domain.
    The first CA instance must create a new security domain. Subsequent CAs can create a new domain or join an existing security domain, but it is recommended that each CA have its own security domain.

    TIP

    If a CA which is a security domain master is cloned, then that cloned CA is also a security domain master. In that case, both the original CA and its clone share the same security domain configuration.
  9. Enter a name for the new instance.
  10. Set up the PKI hierarchy. Commonly, the first CA is a root, or self-signed, CA, meaning that it signs its own CA signing certificate rather than submitting its certificates to a third-party CA for issuance. Subsequent CAs can be subordinate CAs to that root. There are many other options, depending on the PKI environment.
    For a CA, there are two possible configuration options:
    • Root CA. A root CA signs its own CA signing certificate and, therefore, can set its own certificate issuance rules.
    • Subordinate CA. A subordinate CA receives its CA signing certificate from a root CA. The root CA must be referenced here; it can be another Certificate System CA, but this can be an external root CA. The certificate requests generated in this process must be submitted to the external CA and be approved before configuration can be completed.
  11. Fill in the information for the LDAP server which will be used for the instance's internal database. This requires connection information for the Directory Server instance, such as the hostname, port number, bind DN (username), and password. This step also creates a database in the Directory Server and a corresponding base directory entry (base DN) to use for the subsystem's entries.
    To configure SSL client authentication, make sure that the SSL port is set and the SSL checkbox is selected. The Directory Server must be configured to run in SSL, as described in Chapter 7, Installing Red Hat Certificate System with SSL Connections to Red Hat Directory Server.
    The hostname can be the fully-qualified domain name or an IPv4 or IPv6 address, if IPv6 was configured before the packages were installed.

    NOTE

    One thing that can derail subsystem configuration or function is having services that are unable to connect with each other. If servers that need to communicate with each other are on different servers or networks, when the firewalls and iptables must be configured to give the required access.
    If the Red Hat Directory Server instances is on a different server or network than the Certificate System subsystem, then make sure that the Certificate System host's firewall allows access to whatever LDAP port was set in the previous configuration panel.
    Installation will not complete if iptables is not configured properly. To configure iptables, see the Red Hat Enterprise Linux Deployment Guide, such as "Using iptables." It is also possible to simply turn iptables off.
  12. Set the key size and the hashing algorithm (RSA) or curve (ECC) to use for the subsystem instance keys. A root CA has the additional option of selecting the algorithm to use to sign its certificates.
    By default, the settings for the signing key are applied to the keys for every certificate for the CA. To set different key types, sizes, or hashing algorithms (RSA) or curves (ECC) for each certificate, click the [Advanced] link to expand the form so each key pair is listed.
    The default RSA key size is 2048 and for ECC, 256.

    IMPORTANT

    ECC can be used for any keys for the subsystem, with one exception: only RSA can be used for audit signing keys.

    NOTE

    An ECC CA signing certificate can be used to sign both ECC and RSA certificates. If you do not want to use the ECC client certificate that is generated at installation, simply replace the client certificate after configuration, and keep the ECC CA signing certificate.
    Any ECC-enabled PKCS#11 module must be loaded before beginning to configure the CA.
  13. Optionally, change the subject names for the certificates.

    NOTE

    Certificate nicknames must be unique, and changing the default nicknames is one way to ensure that.
    Having unique certificate nicknames is vital for using an HSM, since any nickname conflicts (even for subsystems on different servers) will cause configuration to fail.
  14. The next panels generate and show certificate requests, certificates, and key pairs.
  15. If the subsystem will ever be cloned, or as a protection if keys or certificates are ever lost, back up the keys and certificates when prompted. It is also possible to extract these keys later.
  16. The configuration wizard will prompt to import the new CA certificate. Set all of the trust flags (web, email, and software) and then import the certificate.
  17. Provide the information for the new subsystem administrator.
  18. Click Next through the remaining panels to import the agent certificate into the browser and complete the configuration.
  19. When the configuration is complete, restart the subsystem. 
    service pki-ca restart

    IMPORTANT

    The new instance is not active until it is restarted, and weird behaviors can occur if you try to use the instance without restarting it first.