7.6.2. Setting up CAs

The CA is always the first subsystem to be configured; every other subsystem depends on the CA for its configuration. The CA, along with setting up the CA hierarchy for the PKI, issues certificates which every subsystem uses to function and sets up a security domain which establishes trusted relationships between subsystems.

NOTE

If a CA has an ECC signing certificate, it can issue both RSA and ECC client certificates. To enable ECC for the CA, load an ECC module first (described in Section 9.3, “Installing an Instance with ECC Enabled”) and then configure the CA.
Certificate System does not include a module natively to enable ECC, but it is possible to load and use a third-party PKCS #11 module with ECC-enabled.
Subsystem configuration is done by accessing a unique web-based configuration page for the instance. The only supported web browser for subsystem configuration is Mozilla Firefox. To configure the system silently, through the command line, see Example 11.2, “Configuring a Root CA” and Chapter 11, Silent Configuration for other options.

IMPORTANT

Make sure that the system which the subsystem will run on is properly configured and has all of the necessary prerequisite programs and dependencies. These are described in Section 6.3, “Before Installation: Setting up the Operating Environment”.

7.6.2.1. Configuring a CA

  1. Open the configuration wizard using the URL returned from the package installation.
    Alternatively, log into the setup wizard through 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
  2. Select the token which will store the Certificate System certificates and keys; a list of detected hardware tokens and databases is given.

    IMPORTANT

    Any hardware tokens used with the instance must be configured before configuring the subsystem instance. If the HSM is not properly configured, it may not be listed in the key stores panel or the instance may not function properly. HSM configuration is described in Section 6.3.9.2, “Using Hardware Security Modules with Subsystems”.
    To determine whether a token is detected by the Certificate System, use the TokenInfo tool, as described in Section 6.3.9.4, “Detecting Tokens”.
    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
  3. 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.
  4. Enter a name for the new instance.
  5. 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.
  6. 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 Section 7.5, “Configuring Server SSL Connections Between Red Hat Directory Server and Red Hat Certificate System”.
    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.
  7. 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. To use ECC, you must open the Advanced tab and set the audit signing keys to RSA with the desired algorithm and length. All other keys can use ECC.

    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.
    An ECC module must be loaded for ECC certificates to be generated. Adding ECC support is covered in Section 9.3, “Installing an Instance with ECC Enabled”. Any ECC-enabled PKCS#11 module must be loaded before beginning to configure the CA.
    The hashing algorithms or curves that are available depend on whether RSA or ECC is selected as the key type. The available algorithms and curves are listed in Appendix A, Supported Algorithms and Curves.
  8. 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.
  9. The next panels generate and show certificate requests, certificates, and key pairs.
    If an external CA is used to issue the certificates, configuration cannot go forward until they are received from the external CA. When they are issued, paste the certificates into this panel to add them to the CA database, and then proceed with the installation. Click Apply to view the certificates as they are imported.
  10. 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, as long as they are not stored on an HSM.

    NOTE

    It is not possible to export keys and certificates stored on an HSM to a .p12 file. If this instance will be cloned, use the HSM tools to export the keys when necessary.
  11. 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.
  12. Provide the information for the new subsystem administrator.
  13. Click Next through the remaining panels to import the agent certificate into the browser and complete the configuration.
  14. 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.

IMPORTANT

After setting up the CA subsystems, then look at additional features that can be set up or customized for the Certificate System, such as creating users, adding custom certificate profiles, and configuring backup and restore procedures. The most common features are listed in Chapter 8, After Configuration: Checklist of Configuration Areas for Deploying Certificate System.