Red Hat CERTIFICATE SYSTEM 7.2 - MIGRATION GUIDE, Руководство администратора, Страница: 126 / 512

Chapter 4. Certificate Manager
106
a CA which functions as a root CA within the Certificate System deployment can be subordinate to a
third-party CA.
A Certificate Manager (or CA) is subordinate to another CA because its CA signing certificate,
the certificate that allows it to issue certificates, is issued by another CA. The CA that issued the
subordinate CA signing certificate controls the CA through the contents of the CA signing certificate.
The CA can constrain the subordinate CA through the kinds of certificates that it can issue, the
extensions that it is allowed to include in certificates, the number of level of subordinate CAs the
subordinate CA can create, and the validity period of certificates it can issue, as well as the validity
period of the subordinate CAs signing certificate.
NOTE
Although a subordinate CA can create certificates that violate these constraints, a client
authenticating a certificate that violates those constraints will not accept that certificate.
A self-signed root CA signs its own CA signing certificate and sets its own constraints as well as
setting constraints on the subordinate CA signing certificates it issues.
A Certificate Manager can be configured either a root CA or a subordinate CA. It is easiest to make
the first CA installed a self-signed root, so that it is not necessary to apply to a third party and wait for
the certificate to be issued. Before deploying the full PKI, however, consider whether to have a root
CA, how many to have, and where both root and subordinate CAs will be located.
4.3.1. Subordination to a Public CA
Chaining the Certificate System CA to a third-party public CA introduces the restrictions that public
CAs place on the kinds of certificates the subordinate CA can issue and the nature of the certificate
chain. For example, a CA that chains to a third-party CA might be restricted to issuing only Secure
Multipurpose Internet Mail Extensions (S/MIME) and SSL client authentication certificates, but not
SSL server certificates. There are other possible restrictions with using a public CA. This may not be
acceptable for some PKI deployments.
One benefit of chaining to a public CA is that the third party is responsible for submitting the root CA
certificate to a web browser or other client software. This can be a major advantage for an extranet
with certificates that are accessed by different companies with browsers that cannot be controlled by
the administrator. Creating a root CA in the CA hierarchy means that the local organization must get
the root certificate into all the browsers which will use the certificates issued by the Certificate System.
There are tools to do this within an intranet, but it can be difficult to accomplish with an extranet.
4.3.2. Subordination to a Certificate System CA
Setting up a Certificate System CA as the root CA means that the Certificate System administrator
has control over all subordinate CAs by setting policies that control the contents of the CA signing
certificates issued. A subordinate CA issues certificates by evaluating its own authentication and
certificate profile configuration, without regard for the root CA's configuration.
4.4. Security Domains
A
security domain
is a registry of PKI services. PKI services, such as CAs, register information about
themselves in these domains so users of PKI services can find other services by inspecting the