Self-Signed Root Vs. Subordinate Ca - Red Hat CERTIFICATE SYSTEM 7.1 - ADMINISTRATOR Administrator's Manual

Certificate Manager Deployment Considerations

Self-Signed Root vs. Subordinate CA

A Certificate Manager can be set up as a self-signing root CA. You set up a self-signing
root CA by choosing this option when you install. A self-signing root CA issues and signs
its own certificates. The subsystems are then issued certificates by this self-signing CA.
A Certificate Manager can be setup as a subordinate CA. It can either be subordinate to a
public CA that signs its certificates, or to another CS CA that signs its certificates. A
subordinate CA is restricted in the types of certificates it can issue, and what the content of
those certificates are by the contents and settings of the CA signing certificate issued to it.
For the purposes of an initial pilot, it is easiest to make the CA a self-signed root, so that
you won't need to apply to a third party and wait for the certificate to be issued. Before
deploying a full-blown PKI, however, you will need to consider this question carefully.
Understanding Certificate Manager Subordination
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.
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.
Subordination to a Public CA
If you want your CA to chain up to a third-party public CA, you must carefully consider the
restrictions that public CAs place on the kinds of certificates your CA can issue and the
nature of the certificate chain. For example, a CA that chains up 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. In addition, a CA that
chains up to a third-party CA might not be allowed to have any subordinate CAs and might
have to obey certain restrictions on its use of certificate extensions. These and other
restrictions may be acceptable for some PKI deployments but not for others.
One benefit of chaining up to a public CA is that the third party is responsible for getting the
root CA certificate into the browser or other client software. This can be a major advantage
if you are deploying an extranet that involves certificates used by different companies
whose browsers you cannot control. Alternatively, if you create your own CA hierarchy
from scratch, you are responsible for getting your root certificate into all the browsers used
78 Red Hat Certificate System Administrator's Guide • September 2005