Red Hat CERTIFICATE SYSTEM 8.0 - ADMINISTRATION, Admin Manual

Page: 31 / 564

A Look at Managing Certificates
9
Figure 1.2. CA and DRM
Another aspect of how the subsystems work together is load balancing. If a site has high traffic, then
it is possible to install a lot of CAs, as clones of each other or in a flat hierarchy (where each CA is
independent) or in a tree hierarchy (where some CAs are subordinate to other CAs).
Another option, though is to distribute some of the tasks of a single CA to another subsystem. For
example, if Example Corp. has a manageable number of people requesting certificates for a single
CA to issue. However, because of their security policies, each certificate request has to be verified
in person by an agent, with supporting documentation. This creates a bottleneck for the CA agents
to approve requests. A registration authority (RA) is installed at each local office; the requests are
processed and approved locally, and then a central CA issues all of the certificates.
Figure 1.3. CA and RA
Alternatively, a site may have a significant number of client requests to verify certificate status.
Example Corp. has a large web store, and each customer's browser tries to verify the validity of their
SSL certificates. Again, the CA can handle issuing the number of certificates, but the high request
traffic affects its performance. In this case, Example Corp. uses an external OCSP Manager to verify
certificate statuses, and the Certificate Manager only has to publish updated CRLs every so often.