2.7. Creating Additional Subsystem Instances

2.7. Creating Additional Subsystem Instances

There can be multiple instances of the same type of subsystem on a single machine or multiple instances can be installed on separate machines throughout a deployment. Creating additional subsystem instances is similar to installing and configuring the default instances; there is a script to run to create a basic installation and then an HTML-based configuration wizard.

All additional CA, DRM, OCSP, TKS, and TPS instances are installed by running a special tool, pkicreate. After that, they are configured through the HTML-based administration page. For more information on pkicreate, see the Certificate System Command-Line Tools Guide.

NOTE

Additional subsystems can be duplicates, or clones, of existing subsystems. Cloning can be used for load balancing for heavily trafficked servers and for failover support. Clones are installed the same as other subsystems, with slight differences in the subsequent configuration. For more information on using cloning as part of a deployment strategy, see Chapter 19, Configuring the Certificate System for High Availability.

  1. Run the pkicreate command. Through the options on this tool, the type of subsystem being created, the configuration directory, instance name, port numbers, and other basic configuration information are set. For example, creating a second DRM instance would have the following command: 

    pkicreate -pki_instance_root=/var/lib/rhpki-drm2 -subsystem_type=kra
 -pki_instance_name=rhpki-drm2 -secure_port=10543 -unsecure_port=10180
 -tomcat_server_port=1802 -verbose

    NOTE

    For a TPS subsystem, do not use the tomcat_server_port option since the TPS subsystem uses Apache rather than Tomcat as its web server.

    For more information on the pkicreate tool options, see the Certificate System Command-Line Tools Guide.

  2. When the instance is successfully created, the process returns a URL for the HTML configuration page. For example: 

    http://server.example.com:10180/
 kra/admin/console/config/login?pin=nt2z2keqcqAZiBRBGLDf

  3. Open the new instance URL, and go through the configuration wizard as described in Section 2.6, “Configuring the Default Subsystem Instances”. Supply the security domain, CA, instance ID, internal LDAP database, and agent information.

  4. When the configuration is complete, restart the subsystem.

    /etc/init.d/instance_ID restart

2.7.1. Cloning a Subsystem

For failover protection and for availability for high-traffic subsystems, it is possible to clone an existing CA, DRM, TKS, or OCSP subsystem. To clone a subsystem, do the following:

  1. Create a new instance using pkicreate.

  2. Open the configuration wizard.

  3. In the Security Domain panel, add the clone to the same security domain to which the master belongs.

  4. The Subsystem Type panel sets whether to create a new instance or a clone; select the clone radio button.

    Selecting the Subsystem to Clone

    Figure 2.16. Selecting the Subsystem to Clone

  5. Give the path and filename of the PKCS #12 backup file which was saved when the master instance was created. If a backup was not created at that time, use the pk12util utility to create a PKCS #12 file.

    Supplying the Key and Certificate Information

    Figure 2.17. Supplying the Key and Certificate Information

    NOTE

    When cloning a CA, the master and clone instances have the same CA signing key.

  6. The subsystem information is automatically supplied from the master instance to the clone instance once the keys are successfully restored. Complete the configuration process.

  7. Restart the clone instance.

    /etc/init.d/instance-id restart

For more information on using cloning as part of a deployment strategy, see Chapter 19, Configuring the Certificate System for High Availability.