Este conteúdo não está disponível no idioma selecionado.

Chapter 9. Cloning subsystems


When a new subsystem instance is first configured, the Red Hat Certificate System allows subsystems to be cloned, or duplicated, for high availability of the Certificate System. The cloned instances run on different machines to avoid a single point of failure and their databases are synchronized through replication.

The master CA and its clones are functionally identical, they only differ in serial number assignments and CRL generation. Therefore, this chapter refers to master or any of its clones as replicated CAs.

9.1. Backing up subsystem keys from a software database

Ideally, the keys for the master instance are backed up when the instance is first created. If the keys were not backed up then or if the backup file is lost, then it is possible to extract the keys from the internal software database for the subsystem instance using the PKCS12Export utility. For example:

PKCS12Export -debug -d /var/lib/pki/ instance_name/alias -w p12pwd.txt -p internal.txt -o master.p12
Copy to Clipboard Toggle word wrap

Then copy the PKCS #12 file to the clone machine to be used in the clone instance configuration. For more details, see Section 2.7.6, “Cloning and key stores”.

Note

Keys cannot be exported from an HSM. However, in a typical deployment, HSMs support networked access, as long as the clone instance is installed using the same HSM as the master. If both instances use the same key store, then the keys are naturally available to the clone.

If backing up keys from the HSM is required, contact the HSM manufacturer for assistance.

9.2. Cloning a CA

  1. Configure the master CA, and back up the keys.
  2. In the CS.cfg file for the master CA, enable the master CA to monitor replication database changes by adding the ca.listenToCloneModifications parameter:

    ca.listenToCloneModifications=true
    Copy to Clipboard Toggle word wrap
  3. Create the clone subsystem instance.

    For examples of the configuration file required by pkispawn when cloning CA subsystems, see the Installing a CA clone and Installing a CA clone on the same host sections of the pkispawn(8) man page.

  4. Restart the Directory Server instance used by the clone.

    # systemctl restart pki-tomcatd@kra-clone-ds-instance.service
    Copy to Clipboard Toggle word wrap
    Note

    Restarting the Directory Server reloads the updated schema, which is required for proper performance.

  5. Restart the clone instance.

    # pki-server restart instance_name
    Copy to Clipboard Toggle word wrap

After configuring the clone, test to make sure that the master-clone relationship is functioning:

  1. Request a certificate from the cloned CA.
  2. Approve the request.
  3. Download the certificate to the browser.
  4. Revoke the certificate.
  5. Check master CA’s CRL for the revoked certificate. In the master Certificate Manager’s agent services page, click Update Certificate Revocation List. Find the CRL in the list.

    The CRL should show the certificate revoked by the cloned Certificate Manager. If that certificate is not listed, check logs to resolve the problem.

9.3. Updating CA-KRA connector information after cloning

As covered in Section 2.7.9, “Custom configuration and clones”, configuration information is not updated in clone instances if it is made after the clone is created. Likewise, changes made to a clone are not copied back to the master instance.

If a new KRA is installed or cloned after a clone CA is created, then the clone CA does not have the new KRA connector information in its configuration. This means that the clone CA is not able to send any archival requests to the KRA.

Whenever a new KRA is created or cloned, copy its connector information into all of the cloned CAs in the deployment. To do this, use the pki ca-kraconnector-add command.

If it is required to do this manually, follow these steps:

  1. On the master clone machine, open the master CA’s CS.cfg file, and copy all of the ca.connector.KRA.* lines for the new KRA connector.

    [root@master ~]# vim /var/lib/pki/ instance_name/ca/conf/CS.cfg
    Copy to Clipboard Toggle word wrap
  2. Stop the clone CA instance. For example:

    [root@clone-ca ~]# pki-server stop instance_name
    Copy to Clipboard Toggle word wrap
  3. Open the clone CA’s CS.cfg file.

    [root@clone-ca ~]# vim /var/lib/pki/ instance_name/ca/conf/CS.cfg
    Copy to Clipboard Toggle word wrap
  4. Copy in the connector information for the new KRA instance or clone.

    ca.connector.KRA.enable=true ca.connector.KRA.host=server-kra.example.com
    ca.connector.KRA.local=false ca.connector.KRA.nickName=subsystemCert cert-pki-ca
    ca.connector.KRA.port=10444 ca.connector.KRA.timeout=30
    ca.connector.KRA.transportCert=MIIDbD...ZR0Y2zA==
    ca.connector.KRA.uri=/kra/agent/kra/connector
    Copy to Clipboard Toggle word wrap
  5. Start the clone CA.

    [root@clone-ca ~]# pki-server start instance_name
    Copy to Clipboard Toggle word wrap

9.4. Cloning subsystems

9.4.1. Cloning OCSP subsystems

  1. Configure the master OCSP, 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
    
    OCSP.Responder.store.defStore.refreshInSec=15000
    Copy to Clipboard Toggle word wrap
  3. Create the clone subsystem instance using the pkispawn utility.

    For examples of the configuration file required by pkispawn when cloning OCSP subsystems, see the pkispawn(8) man page.

  4. Restart the Directory Server instance used by the clone.

    # systemctl dirsrv@instance_name.service
    Copy to Clipboard Toggle word wrap
    Note

    Restarting the Directory Server reloads the updated schema, which is required for proper performance.

  5. Restart the clone instance.

    # pki-server restart instance_name
    Copy to Clipboard Toggle word wrap

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.

9.4.2. Cloning KRA subsystems

  1. Configure the master subsystem, and back up the keys.
  2. Create the clone subsystem instance using the pkispawn utility.

    For examples of the configuration file required by pkispawn when cloning KRA subsystems, see the Installing a KRA or TPS clone section of the pkispawn(8) man page.

  3. Restart the Directory Server instance used by the clone.

    # systemctl dirsrv@instance_name.service
    Copy to Clipboard Toggle word wrap
    Note

    Restarting the Directory Server reloads the updated schema, which is required for proper performance.

  4. Restart the clone instance.

    # pki-server restart instance_name
    Copy to Clipboard Toggle word wrap

For the KRA clone, test to make sure that the master-clone relationship is functioning:

  1. Go to the KRA agent’s page.
  2. Click List Requests.
  3. Select Show all requests for the request type and status.
  4. Click Submit.
  5. Compare the results from the cloned KRA and the master KRA. The results ought to be identical.

9.4.3. Cloning TKS subsystems

  1. Configure the master subsystem, and back up the keys.
  2. Create the clone subsystem instance using the pkispawn utility.

    For examples of the configuration file required by pkispawn when cloning TKS subsystems, see the Installing a KRA or TKS clone section of the pkispawn(8) man page.

  3. Restart the clone instance.

    # pki-server restart instance_name
    Copy to Clipboard Toggle word wrap

For the TKS, enroll a smart card and then run an ldapsearch to make sure that the same key information is contained in both databases.

9.5. Converting masters and clones

Only one single active CA generating CRLs can exist within the same topology. Similarly, only one OCSP receiving CRLs can exist within the same topology. As such, there can be any number of clones, but there can only be a single configured master for CA and OCSP.

For KRAs and TKSs, there is no configuration difference between masters and clones, but CAs and OCSPs do have some configuration differences. This means that when a master is taken offline -because of a failure or for maintenance or to change the function of the subsystem in the PKI -then the existing master must be reconfigured to be a clone, and one of the clones promoted to be the master.

9.5.1. Converting CA clones and masters

  1. Stop the master CA if it is still running.
  2. Open the existing master CA configuration directory:

    # cd /var/lib/pki/ instance_name/ca/conf
    Copy to Clipboard Toggle word wrap
  3. Edit the CS.cfg file for the master, and change the CRL and maintenance thread settings so that it is set as a clone:

    • Disable control of the database maintenance thread:

      ca.certStatusUpdateInterval=0
      Copy to Clipboard Toggle word wrap
    • Disable monitoring database replication changes:

      ca.listenToCloneModifications=false
      Copy to Clipboard Toggle word wrap
    • Disable maintenance of the CRL cache:

      ca.crl.IssuingPointId.enableCRLCache=false
      Copy to Clipboard Toggle word wrap
    • Disable CRL generation:

      ca.crl.IssuingPointId.enableCRLUpdates=false
      Copy to Clipboard Toggle word wrap
    • Set the CA to redirect CRL requests to the new master:

      master.ca.agent.host=new_master_hostname
      master.ca.agent.port=new_master_port
      Copy to Clipboard Toggle word wrap
  4. Stop the cloned CA server.

    # pki-server stop instance_name
    Copy to Clipboard Toggle word wrap
  5. Open the cloned CA’s configuration directory.

    # cd /etc/instance_name
    Copy to Clipboard Toggle word wrap
  6. Edit the CS.cfg file to configure the clone as the new master.

    1. Delete each line which begins with the ca.crl. prefix.
    2. Copy each line beginning with the ca.crl. prefix from the former master CA CS.cfg file into the cloned CA’s CS.cfg file.
    3. Enable control of the database maintenance thread; the default value for a master CA is 600.

      ca.certStatusUpdateInterval=600
      Copy to Clipboard Toggle word wrap
    4. Enable monitoring database replication:

      ca.listenToCloneModifications=true
      Copy to Clipboard Toggle word wrap
    5. Enable maintenance of the CRL cache:

      ca.crl.IssuingPointId.enableCRLCache=true
      Copy to Clipboard Toggle word wrap
    6. Enable CRL generation:

      ca.crl.IssuingPointId.enableCRLUpdates=true
      Copy to Clipboard Toggle word wrap
    7. Disable the redirect settings for CRL generation requests:

      master.ca.agent.host=hostname
      master.ca.agent.port=port number
      Copy to Clipboard Toggle word wrap
  7. Start the new master CA server.

    # pki-server start instance_name
    Copy to Clipboard Toggle word wrap

9.5.2. Converting OCSP clones

  1. Stop the OCSP master, if it is still running.
  2. Open the existing master OCSP configuration directory.

    # cd /etc/instance_name
    Copy to Clipboard Toggle word wrap
  3. Edit the CS.cfg, and reset the OCSP.Responder.store.defStore.refreshInSec parameter to 21600:

    OCSP.Responder.store.defStore.refreshInSec=21600
    Copy to Clipboard Toggle word wrap
  4. Stop the online cloned OCSP server.

    # pki-server stop instance_name
    Copy to Clipboard Toggle word wrap
  5. Open the cloned OCSP responder’s configuration directory.

    # cd /etc/instance_name
    Copy to Clipboard Toggle word wrap
  6. Open the CS.cfg file, and delete the OCSP.Responder.store.defStore.refreshInSec parameter or change its value to any non-zero number:

    OCSP.Responder.store.defStore.refreshInSec=15000
    Copy to Clipboard Toggle word wrap
  7. Start the new master OCSP responder server.

    # pki-server start instance_name
    Copy to Clipboard Toggle word wrap

9.6. Cloning a CA that has been re-keyed

When a certificate expires, it has to be replaced. This can either be done by renewing the certificate, which re-uses the original keypair to generate a new certificate, or it can be done by generating a new keypair and certificate. The second method is called re-keying.

When a CA is re-keyed, new keypairs are stored in its certificate database, and these are the keys references for normal operations. However, for cloning a subsystem, the cloning process checks for the CA private key IDs as stored in its CS.cfg configuration file - and those key IDs are not updated when the certificate database keys change.

If a CA has been re-keyed and then an administrator attempts to clone it, the cloned CA fails to generate any certificates for the certificates which were re-keyed, and it shows up in the error logs with this error:

CertUtil::createSelfSignedCert() - CA private key is null!
Copy to Clipboard Toggle word wrap

To clone a CA that has been re-keyed:

  1. Find all of the private key IDs in the CS.cfg file.

    # grep privkey.id /var/lib/pki/ instance_name/ca/conf/CS.cfg
    cloning.signing.privkey.id     =-4d798441aa7230910d4e1c39fa132ea228d5d1bc
    cloning.ocsp_signing.privkey.id =-3e23e743e0ddd88f2a7c6f69fa9f9bcebef1a60
    cloning.subsystem.privkey.id     =-c3c1b3b4e8f5dd6d2bdefd07581c0b15529536
    cloning.sslserver.privkey.id    =3023d30245804a4fab42be209ebb0dc683423a8f
    cloning.audit_signing.privkey.id=2fe35d9d46b373efabe9ef01b8436667a70df096
    Copy to Clipboard Toggle word wrap
  2. Print all of the current private key IDs stored in the NSS database and compare them to the private key IDs stored in the CS.cfg file:

    # certutil -K -d alias
    certutil: Checking token "NSS Certificate DB" in slot "NSS User Private Key and Certificate Services"
    Enter Password or Pin for "NSS Certificate DB":
    < 0> rsa      a7b0944b7b8397729a4c8c9af3a9c2b96f49c6f3   caSigningCert cert-ca4-test-master
    < 1> rsa      6006094af3e5d02aaa91426594ca66cb53e73ac0   ocspSigningCert cert-ca4-test-master
    < 2> rsa      d684da39bf4f2789a3fc9d42204596f4578ad2d9   subsystemCert cert-ca4-test-master
    < 3> rsa      a8edd7c2b5c94f13144cacd99624578ae30b7e43   sslserverCert cert-ca4-test1
    < 4> rsa      2fe35d9d46b373efabe9ef01b8436667a70df096   auditSigningCert cert-ca4-test1
    Copy to Clipboard Toggle word wrap

    In this example, only the audit signing key is the same; the others have been changed.

  3. Take the keys returned in the previous step and convert them from unsigned values (which is what certutil returns) to signed Java BigIntegers (which is how the keys are stored in the Certificate System database).

    This can be done with a calculator or by using the script in Example 9.1, “Certutil to BigInteger conversion program”.

  4. Copy the new key values into the CS.cfg file.

    # vim /var/lib/pki/ instance_name/ca/conf/CS.cfg
    
    cloning.signing.privkey.id     =-584f6bb4847c688d65b373650c563d4690b6390d
    cloning.ocsp_signing.privkey.id =6006094af3e5d02aaa91426594ca66cb53e73ac0
    cloning.subsystem.privkey.id   =-297b25c640b0d8765c0362bddfba690ba8752d27
    cloning.sslserver.privkey.id   =-5712283d4a36b0ecebb3532669dba8751cf481bd
    cloning.audit_signing.privkey.id=2fe35d9d46b373efabe9ef01b8436667a70df096
    Copy to Clipboard Toggle word wrap
  5. Clone the CA as described in Section 9.2, “Cloning a CA”.

Example 9.1. Certutil to BigInteger conversion program

This Java program can convert the key output from certutil to the required BigInteger format.

Save this as a .java file, such as Test.java.

import java.math.BigInteger;

public class Test
{

  public static byte[] hexStringToByteArray(String s) {
      int len = s.length();
      byte[] data = new byte[len / 2];
      for (int i = 0; i < len; i += 2) {
          data[i / 2] = (byte) ((Character.digit(s.charAt(i), 16) << 4)
                               + Character.digit(s.charAt(i+1), 16));
      }
      return data;
  }

  public static void main(String[] args)
  {
      byte[] bytes = hexStringToByteArray(args[0]);
      BigInteger big = new BigInteger (bytes);
      System.out.println("Result is  ==> " + big.toString(16));
  }
}
Copy to Clipboard Toggle word wrap

Then, compile the file:

# javac Test.java
Copy to Clipboard Toggle word wrap
Voltar ao topo
Red Hat logoGithubredditYoutubeTwitter

Aprender

Experimente, compre e venda

Comunidades

Sobre a documentação da Red Hat

Ajudamos os usuários da Red Hat a inovar e atingir seus objetivos com nossos produtos e serviços com conteúdo em que podem confiar. Explore nossas atualizações recentes.

Tornando o open source mais inclusivo

A Red Hat está comprometida em substituir a linguagem problemática em nosso código, documentação e propriedades da web. Para mais detalhes veja o Blog da Red Hat.

Sobre a Red Hat

Fornecemos soluções robustas que facilitam o trabalho das empresas em plataformas e ambientes, desde o data center principal até a borda da rede.

Theme

© 2025 Red Hat