Cloning For Drms; Cloning For Other Subsystems; Cloning And Key Stores - Red Hat CERTIFICATE SYSTEM 8 Install Manual

Cloned CAs do have limits on what operations they can perform. Most important, cloned CAs cannot
generate or publish CRLs. Any CRL requests submitted to a cloned CA are immediately redirected to
the master CA. Anything related to generating or caching CRLs is disabled in the CS.cfg file for the
clone. Clones can revoke, display, import, and download CRLs previously generated by master CAs,
but having them generate new CRLs may cause synchronization problems. Only a single CA should
generate CRLs, and this task is always left to the master CA, which also maintains the CRL cache.
Master CAs also manage the relationships and information sharing between the cloned CAs by
monitoring replication changes to the internal databases.

6.1.2. Cloning for DRMs

With DRMs, all keys archived in one DRM are replicated to the internal databases of the other DRMs.
This allows a key recovery to be initiated on any clone DRM, regardless of which DRM the key was
originally archived on.
After a key recovery is processed, the record of the recovery is stored in the internal database of all of
the cloned DRMs.
Although key recovery can be initiated on any clone, once the recovery is initiated, it must be
completed on the same single DRM. This is because a recovery operation is recorded in the replicated
database only after the appropriate number of approvals have been obtained from the DRM agents.
Until then, the DRM on which the recovery is initiated is the only one which knows about the recovery
operation.

6.1.3. Cloning for Other Subsystems

There is no real operational difference between masters and clones for TKSs; the information created
or maintained on one is replicated along the other servers.
For OCSPs, only the master OCSP receives CRL updates, and then the published CRLs are
replicated to the clones.

6.1.4. Cloning and Key Stores

Cloning a subsystem creates two server processes performing the same functions: another new
instance of the subsystem is created and configured to use the same keys and certificates to perform
its operations. Depending on where the keys are stored for the master clone, the method for the clone
to access the keys is very different.
If the keys and certificates are stored in the internal software token, then the keys must be exported
from the master subsystem when it is first configured. When configuring the master instance, there
is an option in the Export Keys and Certificates panel to back up the keys and certificates to a
PKCS#12 file. Before the clone instance is configured, the PKCS#12 file is copied to the alias/
directory for the clone instance. Then, the PKCS#12 filename is given in the Restore Keys and
Certificates screen during the clone's configuration.
If the keys and certificates are stored on a hardware token, then the keys and certificates can be
copied or referenced directly in the token:
• Duplicate all the required keys and certificates, except the SSL server key and certificate to the
clone instance. Keep the nicknames for those certificates the same. Additionally, copy all the
necessary trusted root certificates from the master instance to the clone instance, such as chains or
cross-pair certificates.
Cloning for DRMs
81