Chapter 11
Certificate Profiles
This chapter describes how to configure certificate profiles. This chapter contains the following sections:
- About Certificate Profiles
- Setting Up Certificate Profiles
- Certificate Profile Reference
- Input Reference
- Output Reference
- Defaults Reference
- Constraints Reference
About Certificate Profiles
A certificate profile defines everything associated with the issuance of a particular type of certificate including the authentication method, the certificate content (defaults), constraints for values associated with that content that can be contained in this type of certificate, and the contents of the input and output forms associated with the certificate profile. Enrollments requests are submitted to a particular certificate profile and are then subject to the defaults and constraints set up in that certificate profile whether the request is submitted via the input form associated with the certificate profile or via some other means. The certificate that is issued from a certificate profile request contains the content defined by the defaults with values derived from the values contained in the parameters associated with those defaults. The constraints provide rules for which content is allowable in the certificate, and defines allowable values for that content.
For example, you could set up a certificate profile for user certificates that defines all aspects of that certificate including the validity period of the issued certificate. You can set a default that defines the default validity period as two years. You would also set up a constraint that the validity period for certificates issued from requests submitted to this certificate profile cannot exceed two years. When a user sends a request using the input form associated with this certificate profile, the certificate issued will contain the information specified in the defaults set up and will be valid for two years. If a user submits a pre formatted request that requests a certificate with a validity period of four years, the request will be rejected since the constraints allow a maximum of two years validity period for this type of certificate.
A set of certificate profiles have been pre built for the most common types of certificates issued. The pre built certificate profiles define defaults and constraints commonly associated with this type of certificate, associate the authentication method common for this type of enrollment, and define the needed inputs and outputs for the certificate profile.
You can use these pre built certificate profiles, you can modify any or all of these by changing the authentication method, the defaults, the constraints used in each policy, the values assigned to any of the parameters in a policy, or the input and output. You can also create other certificate profiles either for other types of certificates, or for creating more than one certificate profile for a type of certificate. You might create more than one certificate profile for a particular type of certificate when you want to issue the same type of certificate with either a different authentication method or different definitions for the defaults and constraints. For example, you might create two certificate profiles used for enrollment for SSL Server certificates where one certificate profile issues certificates with a validity period of six months and another certificate profile issues certificates with a validity period of two years.
A set of defaults and constraints have been pre built for the most commonly used certificate content and constraints. You can set up additional defaults and constraints using the CS SDK.
An input specifies how the enrollment page should be presented, and what inputs should be gathered from the end-entities. You can use inputs to add text fields to the enrollment page so that additional information can be gathered and used for the enrollment. The input values are used as values in the certificate. A set of inputs have been created allowing you to create an enrollment form containing the fields needed for most certificate profiles you will create. The pre built inputs are not configurable in CS; you can change them using the CS SDK. For some options, or for some content you may want to collect, you may need to create additional inputs using the CS SDK. The inputs provide a certificate request field that can be added to any of the forms so that certificate requests can be pasted into this field, allowing a request to be created outside the input form with any of the request information you need.
An output specifies how the response page to a successful enrollment is presented. It usually displays the certificate in a user-readable format. A single output has been created that shows the pretty print version of the resultant certificate. You can create other outputs using the CS SDK.
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 interface where an agent can approve, and thus enable a certificate profile. Once the certificate profile is enabled, it will appear on the Certificate Profile tab of the end-entity interface where end-entity can enroll for a certificate using the certificate profile.
The Certificate Profile enrollment page contains links to each type of certificate profile enrollment 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 for this certificate profile in the end-entity interface is dynamically generated from the inputs defined for this certificate profile. If an authentication plug-in is configured, additional fields may be added that are needed to authenticate the user with that authentication method.
When the 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 under a certificate profile enrollment, showing that it is different from the old enrollment method. The agent can change some aspects of the enrollment, request, validate it, cancel it, reject it, update it, or approve it. The agent can able 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 up; 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.
The issued certificate contains the content defined in the defaults for this certificate profile, such as the extensions and validity period for the certificate, and the content of the certificate is constrained by the constraints set up for each default. You can set up more than one set of policies (defaults and constraints) within one profile, distinguishing each set by using the same value in the Policy Set ID for each set. This is particulary useful for dealing with dual keys enrollment where encryption key and signing key are submitted into the same profile. The server evaluates each set with each request it receives. In the case where a single certificate is issued, one set is evaluated, any other sets are ignored. In the case where 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 if you are issuing a single certificate, or more than two sets if you are issuing dual-key pairs.
The request is not evaluated by the Policies set up in the Policy feature of CS. If the enrollment took place in a Registration Manager, both the Registration Manager and the Certificate Manager should have the same certificate profile implemented with the same policies. The profile in the Certificate Manager will have the final authority.
Setting Up Certificate Profiles
You set up certificate profiles by configuring the existing certificate profiles, deleting an existing certificate profile, or adding another certificate profile and configuring it.
Setting up certificate profiles includes the following process:
- Decide which certificate profiles you will need for your PKI. You will have one certificate profile for each type of certificate you issue, and can have more than one certificate profile for each type of certificate you issue is you want to set up a particular type of certificate with different authentication methods, or different defaults and constraints. Note that any certificate profile available in the administrative interface can be approved by an agent and then used by an end entity to enroll.
- Delete any certificate profiles that you will not use.
- Create any certificate profiles you will need that are not among the pre built certificate profiles.
- Modify the existing certificate profiles and any certificate profiles you have created by changing the following:
- Changing the defaults set up in the certificate profile, the values of the parameters set in the defaults, or the constraints associated with the default to set the content of the issued certificate and the value of that content.
- Changing the constraints set up by changing the value of the parameters in the constraints.
- Changing the authentication method set up for this certificate profile.
- Changing the inputs set up by adding or deleting inputs in the certificate profile thus defining the fields on the input page.
- Add or delete the single output.
- Optionally, you can modify existing defaults, constraints, inputs and outputs, or create new ones using the CS SDK.
Modifying a Certificate Profile
Note that you cannot edit any certificate profile that has been approved by an agent. The agent must disapprove or disable the certificate profile before the administrator can edit that certificate profile.
To add a certificate profile and modify an existing or new certificate profile:
- Log in to the CS window. See "Logging Into the CS Console" on page 239.
- Select the Configuration tab.
- In the navigation tree, select the subsystem to which the certificate profile you want to modify belongs.
- Select Certificate Profiles.
- To modify an existing certificate profile, select a certificate profile listed in the Certificate Profile Instances Management tab and click Edit/View.
- Configure any parameters in the Default or Constraint tab. See "Defaults Reference," on page 428 and "Constraints Reference," on page 453 for complete details for each default or constraint.
- Click Ok.
- Choose the input you want to add from the list and then click OK. See "Input Reference," on page 426 for complete details of the default inputs.
- Delete any certificate profiles you don't want approved by an agent. Any certificate profile that appears in the Certificate Profile Instance Management tab also appears on the Certificate Profiles page in the agent services interface. The certificate profile can be enabled by an agent. If you do not want a certificate profile enabled by an agent, delete that certificate profile from this list by selecting it and then clicking delete.
Certificate Profile Reference
A set of certificate profiles have been prebuilt for the types of certificates that are usually issued by a RA and a CA. All certificate profiles are installed with a CA, only those certificate profiles beginning with ra are installed with and RA. The default certificate profiles include the following:
Input Reference
An input puts certain fields on the enrollment page associated with a particular certificate profile. You define inputs for a certificate profile which are used to dynamically generate the enrollment page.
Certificate Request Input
The Certificate Request Input input is used for enrollments in which a certificate request will be pasted into the enrollment form. It allows the type of request to be specified from a drop down list, and provides an input field to paste the request.
This input puts the following fields into the enrollment form:
Certificate Request Type. This field allows the user to choose the certificate request type of the request they are submitting from the drop down menu. The choices include PKCS#10, CRMF, and CMC.
Certificate Request. This field allows the user to paste a request into the supplied input field.
Dual Key Generation Input
The Dual Key Geneneration Input input is used for enrollments in which dual key pairs will be generated, and thus two certificates issued, one for the signing certificate and one for the encryption certificate. The generation of dual key pairs using the certificate profile interface is only supported for the Netscape 7 and later browsers.
This input puts the following fields into the enrollment form:
Key Generation Request Type. This field is a read only field displaying crmf as the request type. (Note: This field will display Not Supported on browsers other than Netscape 7 and above.)
Key Generation Request. This field is a read only field displaying 1024 (Encryption), 1024 (Signing) as the key generation request. (Note: This field will display Not Supported on browsers other than Netscape 7 and above.)
Key Generation Input
The Key Generation Input input is used for enrollments in which a single key pair will be generated, generally used for user-based certificate enrollments.
This input puts the following fields into the enrollment form:
Key Generation Request Type. This field is a read only field displaying crmf as the request type.
Key Generation Request. This field is a read only field displaying 1024 (High Grade) as the key generation request.
Subject Name Input
The Subject Name Input input is used for enrollment when distinguished name parameters need to be collected from the user. The collected parameters could be used for formulating the subject name in the certificate.
This input puts the following fields into the enrollment form:
UID. This field is for the user ID of this user, as specified for this user in the LDAP directory.
Email. This field is for entering the email address of the user.
Common Name. This field is for entering the name of the user.
Organizational Unit. This field is for entering the organizational unit to which the user belongs.
Organization. This field is for entering the organization name.
Country. This field is for entering the country to which the user belongs.
Submitter Information Input
The Submitter Information Input input is used to collect the certificate requestor's information such as name, email and phone.
This input puts the following fields into the enrollment form:
Requestor Name. This field is used to enter the name of the requestor of this certificate.
Requestor Email. This field is used to enter the email address of the requestor of this certificate.
Requestor Phone. This field is used to enter the phone number of the requestor of this certificate.
Output Reference
An output represents the response to the end user of a successful enrollment.
certOutputImpl
This output displays the certificate in pretty print format. It is the only output defined at this time. You cannot configure or change this output. It does not display anything other than the certificate in pretty print format.
This output needs to be specified for any automated enrollment. Once a user successfully authenticates using the automated enrollment method, the certificate is automatically generated, and this output page is returned to the user. In an agent-approved enrollment, the user can get the certificate, once it is issued, by providing the request id in the end-entity interface; there is no output page associated with agent-approved enrollment.
Defaults Reference
Defaults are used to define the contents of a certificate and the values associated with that content. This section lists the pre built defaults with complete definitions of each.
Authority Info Access Extension Default
This default populates the Authority Info Access extension. This extension specifies how an application validating a certificate can access information, such as on-line validation services and CA policy statements, about the CA that has issued the certificate. Note that this extension should not be used to point directly to the CRL location maintained by a CA; the CRL Distribution Points extension explained in "CRL Distribution Points Extension Default" on page 432 allows you to provide references to CRL locations.
For general information about this extension, see "authorityInfoAccess" on page 731.
You can define the following constraints with this default:
- Extension Constraint, see "Extension Constraint," on page 454
- No Constraints, see "No Constraint," on page 456.
This default allows you to define 5 locations and specify parameters for each location. The parameters are marked with an <n> in the table to distinguish that the parameter is associated with one of the five possible locations.
Authority Key Identifier Extension Default
This default populates the Authority Key Identifier extension into the certificate request. The extension is used to identify the public key that corresponds to the private key used by a CA to sign certificates.
For general information about this extension, see "authorityKeyIdentifier" on page 731.
This default has not parameters. If used, this extension will be included in the certificate with the public key information.
Basic Constraints Extension Default
This default populates Basic Constraint extension in the certificate request. The extension identifies whether or not the Certificate Manager is a CA. The extension is also used during the certificate chain verification process to identify CA certificates and to apply certificate chain-path length constraints.
For general information about this extension, see "basicConstraints" on page 732.
You can define the following constraints with this default:
- Basic Constraints Extension Constraint, see "Basics Constraints Extension Constraint," on page 453
- Extension Constraint, see "Extension Constraint," on page 454
- No Constraints, see "No Constraint," on page 456.
CRL Distribution Points Extension Default
This default populates the CRL Distribution points extension in the certificate request. This extension, when present in a certificate, identifies one or more locations from which an application that is validating the certificate can obtain the CRL information (to verify the revocation status of the certificate).
For general information about this extension, see "CRLDistributionPoints" on page 733.
You can define the following constraints with this default:
- Extension Constraint, see "Extension Constraint," on page 454
- No Constraints, see "No Constraint," on page 456
This default allows you to define 5 locations and specify parameters for each location. The parameters are marked with an <n> in the table to distinguish that the parameter is associated with one of the five possible locations.
Extended Key Usage Extension Default
This default populates the Extended Key Usage extension in the certificate request.
For general information about this extension, see "extKeyUsage" on page 734.
The extension identifies one or more purposes-in addition to or in place of the basic purposes indicated in the key usage extension-for which the certified public key may be used. For example, if the key usage extension identifies a key to be used for signing, the extended key usage extension can further narrow down the usage of the key for signing OCSP responses only or for signing Java applets only.
Note that Windows 2000TM allows you to encrypt files on the hard disk, a feature known as encrypted file system (EFS), using certificates that contain the Extended Key Usage extension with the following two OIDs:
1.3.6.1.4.1.311.10.3.4 (this OID is for the EFS certificate)
1.3.6.1.4.1.311.10.3.4.1 (this OID is for the EFS recovery certificate)
The EFS recovery certificate is used by a recovery agent when a user loses the private key and the data encrypted with that key needs to be used. CS supports the above two OIDs and allows you to issue certificates containing extended key usage extension with these OIDs.
Normal user certificates should be created with only the EFS OID, not the recovery OID.
You can define the following constraints with this default:
- Extended Key Usage Constraint, see "Extended Key Usage Extension Constraint," on page 454
- Extension Constraint, see "Extension Constraint," on page 454
- No Constraints, see "No Constraint," on page 456.
| Parameter |
Description |
|---|---|
| Critical |
Select true to mark this extension critical; select false to mark the extension noncritical. |
| OIDs |
Specifies the OID that identifies a key-usage purpose. Permissible values: A unique, valid OID specified in the dot-separated numeric component notation. Depending on the key-usage purposes, you may choose to use the OIDs designated by PKIX (listed in Table 11-4 on page 434) or define your own OIDs. If you're defining your own OID, it should be in the registered subtree of IDs reserved for your company's use. Although you can invent your own OIDs for the purposes of evaluating and testing this server, in a production environment, you should comply with the ISO rules for defining OIDs and for registering subtrees of IDs. See Appendix H, "Object Identifiers" for information on allocating private OIDs. Example: 2.16.840.1.113730.1.99 |
Freshest CRL Extension Default
This default populates the Freshest CRL extension in the certificate request. The Freshest CRL Extension Default enables you to configure a Certificate Manager to set the FreshestCRL Extension in certificate.
You can define the following constraints with this default:
- Extension Constraint, see "Extension Constraint," on page 454.
- No Constraints, see "No Constraint," on page 456.
This default allows you to define 5 locations and specify parameters for each location. The parameters are marked with an <n> in the table to distinguish that the parameter is associated with one of the five possible locations.
Key Usage Extension Default
This default populates the Key Usage extension in the certificate request. The extension specifies the purposes for which the key contained in a certificate should be used-for example, it specifies whether the key should be used for data signing, key encipherment, or data encipherment-and thus enables you to restrict the usage of a key pair to predetermined purposes.
For general information about this extension, see "keyUsage" on page 736.
You can define the following constraints with this default:
- Key Usage Constraint, see "Key Usage Extension Constraint," on page 455.
- Extension Constraint, see "Extension Constraint," on page 454.
- No Constraints, see "No Constraint," on page 456.
Name Constraints Extension Default
This default populates a name constraint extension in the certificate request. The extension is used in CA certificates to indicate a name space within which subject names or subject alternative names in subsequent certificates in a certification path or chain should be located.
For general information about this extension, see "nameConstraints" on page 737.
You can define the following constraints with this default:
- Extension Constraint, see "Extension Constraint," on page 454.
- No Constraints, see "No Constraint," on page 456.
This default allows you to define 5 locations for both the permitted subtree and the excluded subtree and specify parameters for each of these location. The parameters are marked with an <n> in the table to distinguish that the parameter is associated with one of the five possible locations.