Clone-Master Conversion - Red Hat CERTIFICATE SYSTEM 7.3 - ADMINISTRATION Administration Manual

Chapter 20. Configuring the Certificate System for High Availability
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.
To test the DRM clone, do the following:
1. Go to the DRM 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 DRM and the master DRM.
The results ought to be identical.

20.4. Clone-Master Conversion

At times, an existing cloned subsystem may need converted into a new master subsystem, such as
after catastrophic failure of the existing master. First convert the existing offline master subsystem into
a clone, then convert one of the current existing online cloned subsystems into the new online master
subsystem. The differences between the master and the clone of the different subsystems is illustrated
Table 20.1, "Differences Between Masters and Clones"
in
Subsystem
Certificate Manager
454
Differences
• Master CAs control the database maintenance
thread (this is disabled in cloned CAs)
• Master CAs monitor database replication
changes
• Master CAs maintain the CRL cache
• Master CAs generate the CRL
• Cloned CAs redirect CRL generation requests
Note
Clones should never be configured
to generate CRLs. Clones can
revoke, display, import, and
download CRLs previously
generated by master CAs, but
having them generate new CRLs
may cause synchronization
problems. The rule is that only a