10.4. Cloning OCSP Subsystems

  1. Configure the master OCSP, as described in Section 7.6.4, “Setting up DRMs, OCSPs, and TKSs”, and back up the keys.
  2. In the CS.cfg file for the master OCSP, set the OCSP.Responder.store.defStore.refreshInSec parameter to any non-zero number other than 21600; 21600 is the setting for a clone.
    vim /etc/instance_name/CS.cfg
  3. Create the clone subsystem instance.


    Do not go through the setup wizard for the instance yet.
  4. Copy the exported PKCS#12 file containing the master instance's keys to the clone's alias/ directory.
    The keys for the master instance could have been exported to a .p12 file when the instance was configured. Alternatively, the keys can be exported using the PKCS12Export command, as in Section 10.2, “Exporting Keys from a Software Database”.
  5. Make sure the PKCS#12 file is accessible by the Certificate System user. If necessary, change the file owner to pkiuser and reset the permissions to allow the correct read/write access. For example:
    chown pkiuser:pkiuser example.p12
    chmod 00644 example.p12
  6. It may be necessary to reset the SELinux permissions for the exported file so that the setup program can use it. First, check what context is assigned:
    ls -lZ *
    -rw-------. pkiuser pkiuser system_u:object_r:pki_ocsp_var_lib_t:s0 cert8.db
    -rw-------. pkiuser pkiuser system_u:object_r:pki_ocsp_var_lib_t:s0 key3.db
    -rw-r--r--. pkiuser pkiuser system_u:object_r:nfs_t:s0 example.p12  
    -rw-------. pkiuser pkiuser system_u:object_r:pki_ocsp_var_lib_t:s0 secmod.db
    If it does not match the other security files, then reset the SELinux context to that of the other objects using chcon:
    chcon "system_u:object_r:pki_ocsp_var_lib_t:s0" example.p12
    ls -lZ *
    -rw-------. pkiuser pkiuser system_u:object_r:pki_ocsp_var_lib_t:s0 cert8.db
    -rw-------. pkiuser pkiuser system_u:object_r:pki_ocsp_var_lib_t:s0 key3.db
    -rw-r--r--. pkiuser pkiuser system_u:object_r:pki_ocsp_var_lib_t:s0 example.p12  
    -rw-------. pkiuser pkiuser system_u:object_r:pki_ocsp_var_lib_t:s0 secmod.db
  7. Open the setup wizard URL, which was returned when the instance was created. For example:
  8. In the Security Domain panel, add the clone to the same security domain to which the master belongs.
  9. The Subsystem Type panel sets whether to create a new instance or a clone; select the clone radio button.
  10. Give the path and filename of the PKCS #12 backup file which was saved when the master instance was created or that were exported in 3.
    If the keys are stored on an HSM that is accessible to the clone, then they are picked up automatically.
  11. The subsystem information is automatically supplied from the master instance to the clone instance once the keys are successfully restored. Complete the configuration process.
    When configuring the LDAP database, there are three critical configuration changes that must be made:
    • The clone must use a different Directory Server instance but must have the same suffix name.
    • By default, the instance configuration wizard uses localhost as the location for the internal LDAP database for a new instance. However, with cloning, the configuration process will spin endlessly and never complete if localhost is used for the internal database location, even if the LDAP database is indeed installed on the localhost.
      Use the fully-qualified domain name for the LDAP database in the Internal Database panel when configuring a clone.
    • The subsystem can connect to its database over a special secure port using SSL or over the regular port. However, the clone can only use a secure connection if the master was first set up to use a secure connection to the database, and it must use the same type of connection (SSL or unencrypted) as the master. If the master and clone use a regular, unencrypted connection, then the clone has the option to use Start TLS (a secure connection over an unsecure port) for replication between the master Directory Server database and the clone database.


      Even if the clone connects to the master over a secure connection, the standard LDAP port (389 by default) must still be open and enabled on the LDAP server while cloning is configured.
      For secure environments, the standard LDAP port can be disabled on the master's Directory Server instance once the clone is configured.
  12. Edit the CS.cfg file for the clone. Set the OCSP.Responder.store.defStore.refreshInSec parameter in the clone instance to 21600.
    vim /etc/instance_name/CS.cfg
  13. Restart the Directory Server instance used by the clone.
    service instance_name restart


    Restarting the Directory Server reloads the updated schema, which is required for proper performance.
  14. Restart the clone instance.
    service instance_name start
After configuring the clone, test to make sure that the master-clone relationship is functioning:
  1. Set up OCSP publishing in the master CA so that the CRL is published to the master OCSP.
  2. Once the CRL is successfully published, check both the master and cloned OCSP's List Certificate Authorities link in the agent pages. The list should be identical.
  3. Use the OCSPClient tool to submit OCSP requests to the master and the cloned Online Certificate Status Manager. The tool should receive identical OCSP responses from both managers.