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 Copiar o linkLink copiado para a área de transferência!
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
PKCS12Export -debug -d /var/lib/pki/ instance_name/alias -w p12pwd.txt -p internal.txt -o master.p12
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”.
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 Copiar o linkLink copiado para a área de transferência!
- Configure the master CA, and back up the keys.
In the
CS.cfg
file for the master CA, enable the master CA to monitor replication database changes by adding theca.listenToCloneModifications
parameter:ca.listenToCloneModifications=true
ca.listenToCloneModifications=true
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Create the clone subsystem instance.
For examples of the configuration file required by
pkispawn
when cloning CA subsystems, see theInstalling a CA clone
andInstalling a CA clone on the same host
sections of thepkispawn(8)
man page.Restart the Directory Server instance used by the clone.
systemctl restart pki-tomcatd@kra-clone-ds-instance.service
# systemctl restart pki-tomcatd@kra-clone-ds-instance.service
Copy to Clipboard Copied! Toggle word wrap Toggle overflow NoteRestarting the Directory Server reloads the updated schema, which is required for proper performance.
Restart the clone instance.
pki-server restart instance_name
# pki-server restart instance_name
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
After configuring the clone, test to make sure that the master-clone relationship is functioning:
- Request a certificate from the cloned CA.
- Approve the request.
- Download the certificate to the browser.
- Revoke the certificate.
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 Copiar o linkLink copiado para a área de transferência!
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:
On the master clone machine, open the master CA’s
CS.cfg
file, and copy all of theca.connector.KRA.*
lines for the new KRA connector.vim /var/lib/pki/ instance_name/ca/conf/CS.cfg
[root@master ~]# vim /var/lib/pki/ instance_name/ca/conf/CS.cfg
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Stop the clone CA instance. For example:
pki-server stop instance_name
[root@clone-ca ~]# pki-server stop instance_name
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Open the clone CA’s
CS.cfg
file.vim /var/lib/pki/ instance_name/ca/conf/CS.cfg
[root@clone-ca ~]# vim /var/lib/pki/ instance_name/ca/conf/CS.cfg
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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
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 Copied! Toggle word wrap Toggle overflow Start the clone CA.
pki-server start instance_name
[root@clone-ca ~]# pki-server start instance_name
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
9.4. Cloning subsystems Copiar o linkLink copiado para a área de transferência!
9.4.1. Cloning OCSP subsystems Copiar o linkLink copiado para a área de transferência!
- Configure the master OCSP, and back up the keys.
In the
CS.cfg
file for the master OCSP, set theOCSP.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
# vim /etc/ instance_name/CS.cfg OCSP.Responder.store.defStore.refreshInSec=15000
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Create the clone subsystem instance using the
pkispawn
utility.For examples of the configuration file required by
pkispawn
when cloning OCSP subsystems, see thepkispawn(8)
man page.Restart the Directory Server instance used by the clone.
systemctl dirsrv@instance_name.service
# systemctl dirsrv@instance_name.service
Copy to Clipboard Copied! Toggle word wrap Toggle overflow NoteRestarting the Directory Server reloads the updated schema, which is required for proper performance.
Restart the clone instance.
pki-server restart instance_name
# pki-server restart instance_name
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
After configuring the clone, test to make sure that the master-clone relationship is functioning:
- Set up OCSP publishing in the master CA so that the CRL is published to the master OCSP.
- 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.
-
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 Copiar o linkLink copiado para a área de transferência!
- Configure the master subsystem, and back up the keys.
Create the clone subsystem instance using the
pkispawn
utility.For examples of the configuration file required by
pkispawn
when cloning KRA subsystems, see theInstalling a KRA or TPS clone
section of thepkispawn(8)
man page.Restart the Directory Server instance used by the clone.
systemctl dirsrv@instance_name.service
# systemctl dirsrv@instance_name.service
Copy to Clipboard Copied! Toggle word wrap Toggle overflow NoteRestarting the Directory Server reloads the updated schema, which is required for proper performance.
Restart the clone instance.
pki-server restart instance_name
# pki-server restart instance_name
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
For the KRA clone, test to make sure that the master-clone relationship is functioning:
- Go to the KRA agent’s page.
- Click List Requests.
- Select Show all requests for the request type and status.
- Click .
- Compare the results from the cloned KRA and the master KRA. The results ought to be identical.
9.4.3. Cloning TKS subsystems Copiar o linkLink copiado para a área de transferência!
- Configure the master subsystem, and back up the keys.
Create the clone subsystem instance using the
pkispawn
utility.For examples of the configuration file required by
pkispawn
when cloning TKS subsystems, see theInstalling a KRA or TKS clone
section of thepkispawn(8)
man page.Restart the clone instance.
pki-server restart instance_name
# pki-server restart instance_name
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
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 Copiar o linkLink copiado para a área de transferência!
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 Copiar o linkLink copiado para a área de transferência!
- Stop the master CA if it is still running.
Open the existing master CA configuration directory:
cd /var/lib/pki/ instance_name/ca/conf
# cd /var/lib/pki/ instance_name/ca/conf
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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
ca.certStatusUpdateInterval=0
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Disable monitoring database replication changes:
ca.listenToCloneModifications=false
ca.listenToCloneModifications=false
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Disable maintenance of the CRL cache:
ca.crl.IssuingPointId.enableCRLCache=false
ca.crl.IssuingPointId.enableCRLCache=false
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Disable CRL generation:
ca.crl.IssuingPointId.enableCRLUpdates=false
ca.crl.IssuingPointId.enableCRLUpdates=false
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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
master.ca.agent.host=new_master_hostname master.ca.agent.port=new_master_port
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Stop the cloned CA server.
pki-server stop instance_name
# pki-server stop instance_name
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Open the cloned CA’s configuration directory.
cd /etc/instance_name
# cd /etc/instance_name
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Edit the
CS.cfg
file to configure the clone as the new master.-
Delete each line which begins with the
ca.crl.
prefix. -
Copy each line beginning with the
ca.crl.
prefix from the former master CACS.cfg
file into the cloned CA’sCS.cfg
file. Enable control of the database maintenance thread; the default value for a master CA is
600
.ca.certStatusUpdateInterval=600
ca.certStatusUpdateInterval=600
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Enable monitoring database replication:
ca.listenToCloneModifications=true
ca.listenToCloneModifications=true
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Enable maintenance of the CRL cache:
ca.crl.IssuingPointId.enableCRLCache=true
ca.crl.IssuingPointId.enableCRLCache=true
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Enable CRL generation:
ca.crl.IssuingPointId.enableCRLUpdates=true
ca.crl.IssuingPointId.enableCRLUpdates=true
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Disable the redirect settings for CRL generation requests:
master.ca.agent.host=hostname master.ca.agent.port=port number
master.ca.agent.host=hostname master.ca.agent.port=port number
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
-
Delete each line which begins with the
Start the new master CA server.
pki-server start instance_name
# pki-server start instance_name
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
9.5.2. Converting OCSP clones Copiar o linkLink copiado para a área de transferência!
- Stop the OCSP master, if it is still running.
Open the existing master OCSP configuration directory.
cd /etc/instance_name
# cd /etc/instance_name
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Edit the
CS.cfg
, and reset theOCSP.Responder.store.defStore.refreshInSec
parameter to21600
:OCSP.Responder.store.defStore.refreshInSec=21600
OCSP.Responder.store.defStore.refreshInSec=21600
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Stop the online cloned OCSP server.
pki-server stop instance_name
# pki-server stop instance_name
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Open the cloned OCSP responder’s configuration directory.
cd /etc/instance_name
# cd /etc/instance_name
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Open the
CS.cfg
file, and delete theOCSP.Responder.store.defStore.refreshInSec
parameter or change its value to any non-zero number:OCSP.Responder.store.defStore.refreshInSec=15000
OCSP.Responder.store.defStore.refreshInSec=15000
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Start the new master OCSP responder server.
pki-server start instance_name
# pki-server start instance_name
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
9.6. Cloning a CA that has been re-keyed Copiar o linkLink copiado para a área de transferência!
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!
CertUtil::createSelfSignedCert() - CA private key is null!
To clone a CA that has been re-keyed:
Find all of the private key IDs in the
CS.cfg
file.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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:Copy to Clipboard Copied! Toggle word wrap Toggle overflow In this example, only the audit signing key is the same; the others have been changed.
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”.
Copy the new key values into the
CS.cfg
file.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 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
.
Then, compile the file:
javac Test.java
# javac Test.java