Chapter 9. Additional Installation Options

All Red Hat Certificate System instances created with pkicreate make certain assumptions about the instances being installed, such as the default signing algorithm to use for CA signing certificates and whether to allow IPv6 addresses for hosts.
This chapter describes additional configuration options that impact the installation and configuration for new instances, so many of these procedures occur before the instance is created.

9.1. Requesting Subsystem Certificates from an External CA

Most of the time, it is easier and simpler to have a CA within your PKI be the root CA, since this affords a lot of flexibility for defining the rules and settings of the PKI deployment. However, for public-facing networks, this can be a difficult thing to implement, because web administrators have to find some way to propagate and update CA certificate chains to their clients so that any site is trusted. For this reason, people often use public CAs, hosted by companies like VeriSign or Thawte, to issue CA signing certificates and make all of their CAs subordinate to the public CA. This is one of the planning considerations covered in the Certificate System Deployment Guide.
All subsystem certificates can be submitted to an external CA when the subsystem is configured. When the certificates are generated from a CA outside the Certificate System deployment (or from a Certificate System CA in a different security domain), then the configuration process does not occur in one sitting. The configuration process is on hold until the certificates can be retrieved. Aside from that delay, the process is more or less the same as in Chapter 7, Installing and Configuring Certificate System.
  1. Install the subsystem packages, and open the configuration URL.
  2. Join a security domain. For a CA, it is also possible to create a new security domain.
  3. Set the subsystem information, like its name.
  4. For a CA, set the CA to be a subordinate CA. This is required in order to submit CA subsystem certificates to an external CA; making a root CA automatically generates self-signed certificates.
  5. Set up the internal database.
  6. Select the key store, and generate the key pairs.
  7. Set the subsystem certificate names; you can set these to whatever you want, but make sure that they conform to any requirements that the external CA sets for the subject names of certificates.
    At the bottom of the screen is the list of CAs which are available to accept the submitted certificate requests. Choose External CA from the drop-down menu.
  8. In the Requests and Certificates panel, the CA signing certificate is listed, with an action required label. Once that certificate is generated, the other certificates for the CA will be automatically generated.
    For other subsystems, each subsystem certificate has an action required label and must be submitted to the external CA.
  9. Click the Step 1: Copy the certificate request link, and copy the certificate request to a file or the clipboard.
  10. Submit the request to the external CA. Leave the browser with the configuration wizard open as you wait for the certificates to be generated, so that it is easier to pick up the process.
  11. Click Step 2, and import the certificate chain for the issuing CA. This certificate chain must not contain the leaf certificate (the certificate being requested).
  12. After retrieving the issued certificates, click the Step 3: Paste in the base 64-encoded certificate link, and paste in the new certificate (this should be only the new certificate, not a certificate chain).
  13. For the CA, this only has to be done for the signing certificate. For the other subsystems, repeat steps 9, 10, and 12 for each certificate.
    When all the certificates have been submitted, click Next to resume the configuration process.
  14. Export the keys for the certificates, if the subsystem will be cloned.
  15. Create the administrator user.
  16. When the configuration is done, restart the subsystem.
    service instance_name restart