Red Hat CERTIFICATE SYSTEM 7.3 - ADMINISTRATION, Руководство администратора

Страница: 476 / 554

Chapter 20. Configuring the Certificate System for High Availability
454
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
in
Table 20.1, “Differences Between Masters and Clones”
Subsystem Differences
Certificate Manager • 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