This panel creates a new security domain or adds the new subsystem to an existing security domain. A security domain can be created only if the subsystem being configured is a CA. All other subsystems do not have the option to create a domain, so these subsystems must join an existing security domain. Creating a new domain creates a registry called domain.xml in the /var/lib/CAinstanceID/conf/ directory. Editing the file manually is not recommended.

The first security domain for the Certificate System is created when the default CA is configured. Every subsystem must belong to a security domain; no system can be successfully configured without an existing security domain. The only subsystem which can host a security domain is a CA.

Figure 2.1. Security Domain

If the subsystem is being added to an existing domain, provide the security domain URL and the administrator UID and password for the domain.

Figure 2.2. Supplying the Security Domain Bind Information

For more information on security domains, see Section 4.4, “Security Domains”.

This panel creates a master subsystem or clones an existing subsystem. Creating a master subsystem only requires giving a subsystem name. The subsystem URL is filled automatically. When cloning an existing subsystem, select the master subsystem from the list provided, and give the name of the new cloned subsystem. The list of subsystems in the Clone section list is retrieved from the security domain provided in the Security Domain panel.

Figure 2.3. Creating the Instance

Cloning a subsystem automatically supplies the rest of the subsystem information based on the master's configuration and regenerates the master's certificates.

This option is only available to CAs; this creates the overall arrangement of CAs. CAs can be arranged in a hierarchy, with root CAs, which sign CA signing certificates and set certificate policies, and layers of subordinate CAs, which have CA signing certificates signed by a root CA and which must obey the issuance policies set by that root. This panel determines where in the CA hierarchy the new CA instance belongs.

Figure 2.4. Setting the PKI Hierarchy

For a CA, there are two possible configuration options:

This panel appears only during TPS configuration. This identifies the CA which will work with the TPS to issue, renew, and revoke certificates stored on the smart card. The TPS must be associated with a CA within the security domain which can perform the token operations; the CA is selected from a drop-down list of all CAs within the domain.

Figure 2.5. Selecting the CA

This panel is only available when configuring a TPS subsystem. The TPS must be associated with an existing TKS subsystem. Similarly to setting the CA information, the TKS is selected from a list of all configured TKS subsystems within the security domain.

Figure 2.6. Selecting the TKS

This panel is only available when configuring a TPS subsystem. The TPS can be associated with an existing DRM subsystem to enable server-side key generation. Similarly to setting the CA information, the DRM is selected from a list of all configured DRM subsystems within the security domain.

Figure 2.7. Selecting the DRM

This panel is only available when configuring a TPS subsystem. All subsystems are configured to use a Directory Server database for system certificates and users. The TPS subsystem has an additional database for certificates and keys and to authenticate users which access the Enterprise Security Client. This is configured in the Authentication Directory panel.

Figure 2.8. Configuring the TPS Authentication Database

Directory Server must be installed and available so that information can be supplied in this panel, and the appropriate database and suffix must be created before the TPS is configured; these are not created by the configuration wizard but are accessed by it. Only Red Hat Directory Server 7.1 or higher is supported.

This panel collects information for the internal directory service used for storing certificate requests and certificates.

Directory Server must be installed and available so that information can be supplied in this panel. If the suffix and the database name provided in this screen are not present in the Directory Server instance, then the configuration wizard attempts to create them. It is also possible to provide an existing suffix and database. Only Red Hat Directory Server 7.1 or higher is supported.

Figure 2.9. Configuring the Internal LDAP Database Information

If a subsystem is cloned, the configuration wizard attempts to configure multi-master replication agreements between the master subsystem's internal database and the new clone's internal database.

This panel displays a list of automatically-discovered tokens that can be used to store certificates and keys. The Certificate System automatically discovers Safenet's LunaSA and nCipher's netHSM hardware security modules (HSM) and returns them on this screen. The discovery process assumes that the client software installations for these modules are local on the same system as the Certificate System subsystem and are in the following locations:

Figure 2.10. Selecting the Key and Certificate Location

The LunaSA partitions, the nCipher slots, and the NSS internal software token are provided in this screen.

The internal software token is logged in by default. The password to this database is stored in /var/lib/instance_ID/conf/password.conf.

If an HSM module is selected, the administrator provides the password, and password.conf is updated with this information by default.

The status field in this panel describes the status of the token.

The login button corresponding to the slot brings up a login prompt for the token password.

This screen shows the type and size of the keys to be generated. The default values are RSA and 2048-bit for all keys.

Figure 2.11. Setting the Key Pair Type

This panel lists the different certificate subject names for all of the certificates issued for the subsystem being installed. This panel also sets which CA will issue these certificates. If the certificates for the subsystem, including certificates for a subordinate CA, will be issued by an external CA such as VeriSign or a Certificate System CA which is outside the security domain, select External CA from the list.

Figure 2.12. Setting the Certificate Subject Name

If an existing subsystem is being cloned, all of these fields are grayed out except the Server Certificate name field because the server certificate is regenerated.

This panel has links to the certificate requests and the issued certificates, if the certificates were issued successfully. The generated certificate requests are stored in the instance's CS.cfg configuration file for retrieval later.

Figure 2.13. Certificate Request and Certificate Links

If the certificates are signed by an external CA, such as a third-party CA or a Certificate System CA which is outside the security domain, then action required is shown under the certificate name, and there are action links to submit the certificate. The configuration wizard will not proceed past this panel until the new certificates are pasted into the fields. In this case, the Requests and Certificates panel appears as shown.

This panel offers the option to export the new certificate to a .p12 file. A .p12 backup file of a master subsystem's certificates and keys is required when configuring the clone; these files can also be used to restore the keys and certificates if the current certificate repository, such as a token, is lost or damaged.

Figure 2.14. Exporting the Certificates and Keys

This panel creates the first administrator user for the instance. This user also has agent privileges, so the agent certificates and keys for the agent certificate are generated on the browser used to go through the configuration wizard. This administrator/agent user can use this agent certificate to access the agent interface for managing requests.

Figure 2.15. CA Administrator

Pressing Next causes the browser to generate a key pair which consists of a public key and a private key. The public key is packaged in a certificate request that is submitted to the CA. If the requests are submitted to a Certificate System CA, the CA approves and signs the certificate request automatically, and the certificate is returned in the browser in the next panel.