Ce contenu n'est pas disponible dans la langue sélectionnée.
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 Copier lienLien copié sur presse-papiers!
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 Copier lienLien copié sur presse-papiers!
- Configure the master CA, and back up the keys.
In the
CS.cfgfile for the master CA, enable the master CA to monitor replication database changes by adding theca.listenToCloneModificationsparameter:ca.listenToCloneModifications=true
ca.listenToCloneModifications=trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow Create the clone subsystem instance.
For examples of the configuration file required by
pkispawnwhen cloning CA subsystems, see theInstalling a CA cloneandInstalling a CA clone on the same hostsections 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.serviceCopy 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_nameCopy 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 Copier lienLien copié sur presse-papiers!
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.cfgfile, 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.cfgCopy 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_nameCopy to Clipboard Copied! Toggle word wrap Toggle overflow Open the clone CA’s
CS.cfgfile.vim /var/lib/pki/ instance_name/ca/conf/CS.cfg
[root@clone-ca ~]# vim /var/lib/pki/ instance_name/ca/conf/CS.cfgCopy 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/connectorCopy to Clipboard Copied! Toggle word wrap Toggle overflow Start the clone CA.
pki-server start instance_name
[root@clone-ca ~]# pki-server start instance_nameCopy to Clipboard Copied! Toggle word wrap Toggle overflow
9.4. Cloning subsystems Copier lienLien copié sur presse-papiers!
9.4.1. Cloning OCSP subsystems Copier lienLien copié sur presse-papiers!
- Configure the master OCSP, and back up the keys.
In the
CS.cfgfile for the master OCSP, set theOCSP.Responder.store.defStore.refreshInSecparameter 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=15000Copy to Clipboard Copied! Toggle word wrap Toggle overflow Create the clone subsystem instance using the
pkispawnutility.For examples of the configuration file required by
pkispawnwhen 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.serviceCopy 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_nameCopy 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
OCSPClienttool 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 Copier lienLien copié sur presse-papiers!
- Configure the master subsystem, and back up the keys.
Create the clone subsystem instance using the
pkispawnutility.For examples of the configuration file required by
pkispawnwhen cloning KRA subsystems, see theInstalling a KRA or TPS clonesection of thepkispawn(8)man page.Restart the Directory Server instance used by the clone.
systemctl dirsrv@instance_name.service
# systemctl dirsrv@instance_name.serviceCopy 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_nameCopy 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 Copier lienLien copié sur presse-papiers!
- Configure the master subsystem, and back up the keys.
Create the clone subsystem instance using the
pkispawnutility.For examples of the configuration file required by
pkispawnwhen cloning TKS subsystems, see theInstalling a KRA or TKS clonesection of thepkispawn(8)man page.Restart the clone instance.
pki-server restart instance_name
# pki-server restart instance_nameCopy 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 Copier lienLien copié sur presse-papiers!
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 Copier lienLien copié sur presse-papiers!
- 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/confCopy to Clipboard Copied! Toggle word wrap Toggle overflow Edit the
CS.cfgfile 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=0Copy to Clipboard Copied! Toggle word wrap Toggle overflow Disable monitoring database replication changes:
ca.listenToCloneModifications=false
ca.listenToCloneModifications=falseCopy to Clipboard Copied! Toggle word wrap Toggle overflow Disable maintenance of the CRL cache:
ca.crl.IssuingPointId.enableCRLCache=false
ca.crl.IssuingPointId.enableCRLCache=falseCopy to Clipboard Copied! Toggle word wrap Toggle overflow Disable CRL generation:
ca.crl.IssuingPointId.enableCRLUpdates=false
ca.crl.IssuingPointId.enableCRLUpdates=falseCopy 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_portCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Stop the cloned CA server.
pki-server stop instance_name
# pki-server stop instance_nameCopy to Clipboard Copied! Toggle word wrap Toggle overflow Open the cloned CA’s configuration directory.
cd /etc/instance_name
# cd /etc/instance_nameCopy to Clipboard Copied! Toggle word wrap Toggle overflow Edit the
CS.cfgfile 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.cfgfile into the cloned CA’sCS.cfgfile. Enable control of the database maintenance thread; the default value for a master CA is
600.ca.certStatusUpdateInterval=600
ca.certStatusUpdateInterval=600Copy to Clipboard Copied! Toggle word wrap Toggle overflow Enable monitoring database replication:
ca.listenToCloneModifications=true
ca.listenToCloneModifications=trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow Enable maintenance of the CRL cache:
ca.crl.IssuingPointId.enableCRLCache=true
ca.crl.IssuingPointId.enableCRLCache=trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow Enable CRL generation:
ca.crl.IssuingPointId.enableCRLUpdates=true
ca.crl.IssuingPointId.enableCRLUpdates=trueCopy 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 numberCopy 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_nameCopy to Clipboard Copied! Toggle word wrap Toggle overflow
9.5.2. Converting OCSP clones Copier lienLien copié sur presse-papiers!
- Stop the OCSP master, if it is still running.
Open the existing master OCSP configuration directory.
cd /etc/instance_name
# cd /etc/instance_nameCopy to Clipboard Copied! Toggle word wrap Toggle overflow Edit the
CS.cfg, and reset theOCSP.Responder.store.defStore.refreshInSecparameter to21600:OCSP.Responder.store.defStore.refreshInSec=21600
OCSP.Responder.store.defStore.refreshInSec=21600Copy to Clipboard Copied! Toggle word wrap Toggle overflow Stop the online cloned OCSP server.
pki-server stop instance_name
# pki-server stop instance_nameCopy to Clipboard Copied! Toggle word wrap Toggle overflow Open the cloned OCSP responder’s configuration directory.
cd /etc/instance_name
# cd /etc/instance_nameCopy to Clipboard Copied! Toggle word wrap Toggle overflow Open the
CS.cfgfile, and delete theOCSP.Responder.store.defStore.refreshInSecparameter or change its value to any non-zero number:OCSP.Responder.store.defStore.refreshInSec=15000
OCSP.Responder.store.defStore.refreshInSec=15000Copy to Clipboard Copied! Toggle word wrap Toggle overflow Start the new master OCSP responder server.
pki-server start instance_name
# pki-server start instance_nameCopy to Clipboard Copied! Toggle word wrap Toggle overflow
9.6. Cloning a CA that has been re-keyed Copier lienLien copié sur presse-papiers!
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.cfgfile.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.cfgfile: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
certutilreturns) 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.cfgfile.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