Red Hat CERTIFICATE SYSTEM 7.2 - MIGRATION GUIDE, Руководство администратора

Страница: 258 / 512

Chapter 12. Certificate Profiles
238
Policy sets are sets of constraints and default extensions attached to every certificate processed
through the profile. The extensions define certificate content such as validity periods and subject name
requirements. A profile handles one certificate request, but a single request can contain information
for multiple certificates. A PKCS#10 request contains a single public key. One CRMF request can
contain multiple public keys, meaning multiple certificate requests. A profile may contain multiple sets
of policies, with each set specifying how to handle one certificate request within a CRMF request.
12.2. How Certificate Profiles Work
An administrator sets up a certificate profile by associating an existing authentication plug-in, or
method, with the certificate profile; enabling and configuring defaults and constraints; and defining
inputs and outputs. The administrator can use the existing certificate profiles, modify the existing
certificate profiles, create new certificate profiles, and delete any certificate profile that will not be used
in this PKI.
Once a certificate profile is set up, it appears on the
Manage Certificate Profiles
page of the agent
services page where an agent can approve, and thus enable, a certificate profile. Once the certificate
profile is enabled, it appears on the
Certificate Profile
tab of the end-entities page where end entities
can enroll for a certificate using the certificate profile.
The certificate profile enrollment page in the end-entities interface contains links to each certificate
profile that has been enabled by the agents. When an end entity selects one of those links, an
enrollment page appears containing an enrollment form specific to that certificate profile. The
enrollment page is dynamically generated from the inputs defined for the profile. If an authentication
plug-in is configured, additional fields may be added to authenticate the user.
When an end entity submits a certificate profile request that is associated with an agent-approved
(manual) enrollment, an enrollment where no authentication plug-in is configured, the certificate
request is queued in the agent services interface. The agent can change some aspects of the
enrollment, request, validate it, cancel it, reject it, update it, or approve it. The agent is able to update
the request without submitting it or validate that the request adheres to the profile's defaults and
constraints. This validation procedure is only for verification and does not result in the request being
submitted. The agent is bound by the constraints set; they cannot change the request in such a way
that a constraint is violated. The signed approval is immediately processed, and a certificate is issued.
When a certificate profile is associated with an authentication method, the request is approved
immediately and generates a certificate automatically if the user successfully authenticates, all the
information required is provided, and the request does not violate any of the constraints set up for the
certificate profile. There are profile policies which allow user-supplied settings like subject names or
validity periods. The certificate profile framework can also preserve user-defined content set in the
original certificate request in the issued certificate.
The issued certificate contains the content defined in the defaults for this certificate profile, such as
the extensions and validity period for the certificate. The content of the certificate is constrained by
the constraints set for each default. Multiple policies (defaults and constraints) can be set for one
profile, distinguishing each set by using the same value in the policy set ID. This is particularly useful
for dealing with dual keys enrollment where encryption keys and signing keys are submitted to the
same profile. The server evaluates each set with each request it receives. When a single certificate
is issued, one set is evaluated, and any other sets are ignored. When dual-key pairs are issued, the
first set is evaluated with the first certificate request, and the second set is evaluated with the second
certificate request. There is no need for more than one set for issuing a single certificate or more than
two sets for issuing dual-key pairs.