Subordination To A Public Ca; Subordination To A Certificate System Ca; Linked Ca; Ca Cloning - Red Hat CERTIFICATE SYSTEM 8 - DEPLOYMENT Deployment Manual

Chapter 5. Planning the Certificate System
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.

5.2.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.

5.2.2. Subordination to a Certificate System CA

The Certificate System CA can function as a root CA, meaning that the server signs its own CA
signing certificate as well as other CA signing certificates, creating an organization-specific CA
hierarchy. The server can alternatively be configured as a subordinate CA, meaning the server's CA
signing key is signed by another CA in an existing CA hierarchy.
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.

5.2.3. Linked CA

The Certificate System Certificate Manager can function as a linked CA, chaining up to many third-
party or public CAs for validation; this provides cross-company trust, so applications can verify
certificate chains outside the company certificate hierarchy. A Certificate Manager is chained to a third-
party CA by requesting the Certificate Manager's CA signing certificate from the third-party CA.
Related to this, the Certificate Manager also can issue cross-pair or cross-signed certificates. Cross-
pair certificates create a trusted relationship between two separate CAs by issuing and storing cross-
signed certificates between these two CAs. By using cross-signed certificate pairs, certificates issued
outside the organization's PKI can be trusted within the system.
These are also called bridge certificates, related to the Federal Bridge Certification Authority (FBCA)
definition.

5.2.4. CA Cloning

Instead of creating a hierarchy of root and subordinate CAs, it is possible to create multiple clones of a
Certificate Manager and configure each clone to issue certificates within a range of serial numbers.
A cloned Certificate Manager uses the same CA signing key and certificate as another Certificate
Manager, the master Certificate Manager.
62