| Administrator's Guide Red Hat Certificate System |
| Previous |
Contents |
Index |
Next |
Chapter 12
Policies
Red Hat Certificate System (CS) provides a customizable policy framework for the Certificate Manager, Registration Manager, and Data Recovery Manager. This chapter explains how to configure these subsystems to apply organizational and other policies on incoming certificate and key-related requests.
Note: This feature is provided for legacy purposes. If you are new to this product, you should stay with the newer (default) certificate enrollment feature: Certificate Enrollment Profiles (see Chapter 11, "Certificate Profiles"). The policies feature will be discontinued in the future release(s). To enable the feature, you need to copy all the files under: <serverRoot>/bin/cert/forms/ee/<subsystem>/policyEnrollment/ to <serverRoot>/cert-<instanceID>/web-apps/ee/<subsystem>/, where subsystem is either ca or ra.
This chapter contains the following sections:
- Introduction to Policy
- Configuring Policy Rules for a Subsystem
- Using JavaScript for Policies
- Constraints-Specific Policy Module Reference
- Extension-Specific Policy Module Reference
- Managing Policy Plug-in Modules
Introduction to Policy
You can configure the main subsystems of CS-the Certificate Manager, Registration Manager, and Data Recovery Manager-to apply certain organizational policies on an end-entity's certificate enrollment and management requests before servicing them. For example, some of the policies you might want a Certificate Manager to impose on these requests may include setting a minimum and maximum limit on validity period and key length of certificates, setting extensions based on the end entity's role within an organization, setting signing algorithms, and so on.
This section provides an overview of policy in general. Topics include:
About Policy
Policy refers to a set of rules that CS uses to evaluate or verify an incoming request from an end entity and to determine the outcome; the incoming requests that are governed by policies include certificate issuance, certificate renewal, certificate revocation, key archival, and key recovery requests. For example, in the case of a certificate issuance request, the outcome would be the certificate content.
- A Certificate Manager's policy can include rules for evaluating certificate formulation, signing, renewal, and revocation requests. For example, you can configure a Certificate Manager's policy to impose restrictions on validity length, key type, key length, subject name, extensions, and signing algorithm during certificate issuance.
- A Registration Manager's policy can include rules for verifying incoming certificate issuance, renewal, and revocation requests from end entities in order to formulate the certificate content before forwarding the requests to a Certificate Manager for signing. For example, you can configure a Registration Manager's policy to impose restrictions on validity period, key length, subject name, and extensions. In general, policies for Registration Manager are largely the same as for Certificate Manager.
- A Data Recovery Manager's policy can include rules for verifying users' encryption private key archival and recovery requests.
Using policies, you can configure CS to perform one or more of the following operations on each certificate issuance or management request it receives:
- Screen the request for specific content, and modify, reject, or defer (for agent approval) it accordingly. For example, the request might be checked for the inclusion of organizational constraints, such as key algorithm, key size, validity period, or a particular signing algorithm; if it did not meet the requirement, the subsystem would modify the request or return an error, depending on the severity of the problem.
- Set common attributes, such as extensions for user and server certificate requests.
Policy Rules
A policy rule refers to a uniquely configured instance of any policy plug-in implementation. For example, you can use the plug-in module provided for setting validity periods on certificates to configure a policy rule that forces validity periods for all client certificates issued by a Certificate Manager to fall within a predetermined range, say between 6 and 24 months. A subsystem's policy configuration can consist of one or more policy rules, each performing one or more of the following operations:
- Validate the request content by comparing it with configured criteria; reject, modify, or defer (for agent approval) the request if any of the request parameters are invalid.
- Build certificate content-for example, set common extensions and the validity period.
- Enforce organizational constraints, such as subject name, key algorithm, key size, and validity period.
- Determine whether the private key should be archived.
Keep in mind that the server applies the rules when processing end-entity requests and after agent approval (for deferred requests).
Types of Policy Rules
CS supports distinct policy rules for each of the operations that end-entities perform-certificate enrollment, renewal, and revocation, and key archival and recovery. Consequently, there are five broad categories of policies, corresponding to these types of operations:
- Enrollment policies
- Renewal policies
- Revocation policies
- Key-archival policies
- Key-recovery policies
To facilitate this classification, CS supports a parent interface for a generic policy rule and other operation-specific interfaces that extend the parent interface. Check the CS SDK.
Policy Processor
Each subsystem-the Certificate Manager, Registration Manager, or Data Recovery Manager-has its own policy processor. Each processor subjects an incoming request to the applicable policy rules for that subsystem.
When a subsystem starts up, its policy processor reads the current policy configurations from the configuration file, initializes them, and classifies them based on their type (see "Types of Policy Rules" on page 463). Then, when the subsystem receives an authenticated request, its request processor invokes the policy processor to apply policies on that request. The policy processor applies the rules on the request based on the request type. The policy processor also filters the rules based on predicates (see "Using Predicates in Policy Rules" on page 465).
Note that the policy processor applies only the enabled policy rules, in the order in which they are configured, before determining the final outcome. Each rule the processor executes returns a PolicyResult object. Three return values are possible:
- PolicyResult.REJECTED (indicates that the request failed the rule)
- PolicyResult.DEFERRED (indicates that the request requires agent approval)
- PolicyResult.ACCEPTED (indicates that the request passed the rule)
After all the policy rules are applied, the processor determines the status of the request (in this order):
- If the request failed any policy rule (that is, if any of the policy rules returned a PolicyResult.REJECTED value), the processor rejects the request. The rule that rejected the request sets appropriate error messages on the request.
- If at least one of the policy rules requires agent approval for the request (that is, if any of the policy rules returned a PolicyResult.DEFERRED value), the processor stores the request in the request queue for agent approval.
- If the request passes all the policy rules (that is, all policy rules returned a PolicyResult.ACCEPTED value), the request gets serviced-for example the certificate is issued or renewed.
Using Predicates in Policy Rules
You can use predicates in a policy rule. A predicate indicates whether the rule that contains the predicate applies to a request. If you specify a predicate as part of the rule configuration, the policy rule applies that predicate based on request attributes to determine whether the rule is applicable for a request.
The policy predicate is a logical expression. You form the expression using variables and relational operators (AND or OR). For example, you could set up a predicate to put the CRL Distribution Point extension only in SSL client certificates, or set different validity dates for certificates for users in different groups.
The following are sample predicates:
HTTP_PARAMS.certType==client AND HTTP_PARAMS.ou==Engineering
HTTP_PARAMS.certType==server AND HTTP_PARAMS.o==Netscape OR HTTP_PARAMS.certType==ca
Expression Support for Predicates
You form an expression using an attribute, its value, and one or more of the operators listed in Table 12-1. For a list of attributes, see "Attributes for Predicates" on page 467.
Table 12-1 Predicates in policy: supported comparison and logical operators
Note that the expression parsing support currently supports only two comparison operators (==, !=) and two relational operators (AND, OR).
Policy expressions are formed with the following rules:
PrimitiveExpression | AndExpression | OrExpression
- PrimitiveExpression is equal to: Attribute op Value, where
Attribute can be a string
op can be any of these operators: == or !=
Value can be a string- AndExpression is equal to: Expression AND Expression
- OrExpression is equal to: Expression OR Expression
In an expression, the AND operator takes precedence over an OR operator. For example, the expression
HTTP_PARAMS.certType==client AND HTTP_PARAMS.ou==Engineering OR HTTP_PARAMS.certType==ca
(HTTP_PARAMS.certType==client AND HTTP_PARAMS.ou==Engineering) OR HTTP_PARAMS.certType==ca
CS evaluates an expression based on the attributes in the request. The attributes are filled in by servlets from the HTTP input forms used for request submission. Some attributes, such as passwords typed in the form are not stored in the request. Other attributes regarding the end entity, such as the user ID, are set on the request after successful authentication. The servlets also interpret the form content, for example, retrieving the key material out of the KEYGEN or PKCS #10 information and setting the key in the certificate content. They can also set additional attributes related to the certificate content on the request. In general, you can configure which attributes-for example, sensitive attributes such as passwords-should or shouldn't be stored in the request.
Note that all data related to an end entity is gathered at the servlet level and set on the request before the request is passed to the policy subsystem. The policy subsystem applies configured policy rules on the request, determines whether the request needs agent approval, performs constraint- and extension-specific checks on the request attributes, and then formulates the certificate content by adding the appropriate information, such as the validity period and extensions.
The expression queries the request for the attributes, compares the value returned with the value provided in the predicate, and returns a boolean result.
Be aware that if the same name is in an HTTP form input and authentication token (authentication result) the authentication result can override the HTTP form input. For example, if email is in an HTTP input and an authentication module also puts email in the authentication result (that is, authtoken) the email value from the authentication module will override the email value from the HTTP input in the request. A predicate using email in an expression will be evaluated to the value of the authentication instead of the HTTP input value.
The following are sample predicates:
HTTP_PARAMS.certType==client AND HTTP_PARAMS.ou==Engineering
HTTP_PARAMS.certType==server AND HTTP_PARAMS.o==Netscape OR HTTP_PARAMS.certType==ca
Attributes for Predicates
Attributes for predicates can come from any of the following:
- Input form-that is, the HTML form that end entities use for submitting certificate requests.
- Authentication token-what the authentication subsystem returns after successfully authenticating an end entity.
- A service-for example, a Certificate Manager, Registration Manager, or Data Recovery Manager service can add certain attributes to the end-entity request.
- Policy processor-what the policy subsystem returns after subjecting the end-entity request to policy checking. For example, an extension-based policy can set an appropriate extension in the certificate.
Table 12-2 lists default attributes that are supported by various request object implementations.
Table 12-2 Attributes supported by request object implementations
- ca (Certificate Manager's CA signing certificate)
- caCrlSigning (Certificate Manager's CRL signing certificate)
- CEP-Request (router certificate)
- client (client certificates)
- codeSignClient (Object signing certificate - PKCS#10)
- objSignClient (Object signing certificate - Browser)
- ocspResponder (OCSP Responder certificate)
- other
- ra (Registration Manager's signing certificate)
- server (SSL server certificate)
You can define your own attributes for predicates, if there's a need. For example, assume you have two organizational units Sales and Manufacturing and you want to issue client certificates with different validity periods to users in these two units. A quick and easy way to accomplish this would be to define a new attribute for the organizational unit, add the attribute to the enrollment form that the users in these organizational units use for certificate enrollment (so that the server receives it from the HTTP input), and use the attribute in the predicate expression for the validity constraints policy-a policy rule that determines the validity period of certificates the server issues. For details on this policy, see "ValidityConstraints," on page 487.
Note that to define a new attribute in any of the HTML forms, all you need to do is to add the following line to the corresponding HTML form:
<input type="HIDDEN" name="attribute_name" value="attribute_value">Assuming that the new attribute you define for the organizational unit is orgunit, the line you would add to the enrollment form would be:
<input type="HIDDEN" name="orgunit" value="Sales">
To add this line to an enrollment form, you would:
- Open the corresponding HTML file in a text editor.
- Locate the section that lists the HTTP input variables.
- Add this line: <input type="HIDDEN" name="orgunit" value="Sales">
- Save your changes and close the file.
For the server to use the attribute (to distinguish enrollment requests from users in the Sales unit versus those in the Manufacturing unit) to issue certificates with the appropriate validity periods, you must formulate your predicate expression with the attribute you added. Here's how you do this:
- Create a new instance of the ValidityConstraints policy plug-in implementation.
- Enter the appropriate values for all the attributes.
Assume you named the instance ValidityRule1, set the minimum validity period to 10 days, set the maximum validity period to 180 days, defined the predicate expression as HTTP_PARAMS.certType==client AND HTTP_PARAMS.orgunit==Sales. (This expression specifies that the policy be applied to only client certificate requests from users in the organizational unit named Sales.)
- A sample of the resulting configuration entries in the CS configuration file would be as follows:
ca.Policy.rule.ValidityRule1.enable=true ca.Policy.rule.ValidityRule1.implName=ValidityConstraints ca.Policy.rule.ValidityRule1.maxValidity=180 ca.Policy.rule.ValidityRule1.minValidity=10 ca.Policy.rule.ValidityRule1.predicate=HTTP_PARAMS.certType== client AND HTTP_PARAMS.orgunit==Sales
- Now, for setting the validity period in certificates of users who are not in the Sales organization-in this case, this would be Manufacturing-you would create another instance of ValidityConstraints policy rule as before with a different set of values.
- Assume you named the instance ValidityRule1, set the maximum validity period to 60 days, set the minimum validity period to 10 days, defined the predicate expression as HTTP_PARAMS.certType==client AND HTTP_PARAMS.orgunit!=Sales. (This expression specifies that the policy be applied to only client certificate requests from users who are not in the organizational unit named Sales.)
- A sample of the resulting configuration entries in the CS configuration file would be as follows:
ca.Policy.rule.ValidityRule2.enable=true ca.Policy.rule.ValidityRule2.implName=ValidityConstraints ca.Policy.rule.ValidityRule2.maxValidity=60 ca.Policy.rule.ValidityRule2.minValidity=10 ca.Policy.rule.ValidityRule2.predicate=HTTP_PARAMS.certType== client AND HTTP_PARAMS.orgunit!=SalesThe new configuration would result in certificates with a validity period of six months for users in the Sales organizational unit and a validity period of three months for users in the Manufacturing unit.
Configuring Policy Rules for a Subsystem
You can configure the main subsystems of CS (CS)-the Certificate Manager, Registration Manager, and Data Recovery Manager-to apply certain organizational policies on end entities' certificate enrollment, renewal, and revocation requests before servicing them. This section explains how to configure a subsystem to evaluate end-entity requests based on a set of policy rules.
Modifying Policy Rules
To modify existing policy rules:
- 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 policy rule you want to modify belongs.
- Select Policies.
Deleting Policy Rules
You can delete any unwanted policy rules from the CS configuration. If you think you might need a rule in the future, instead of deleting it from the configuration you should disable it by deselecting the enable parameter. In this way, you can avoid re-creating the rule in the future. Because the subsystems subject end-entity requests only to rules that are currently enabled, keeping unwanted rules in the disabled state in the configuration does not affect policy decisions made by a subsystem.
To delete a policy rule from the CS configuration:
- In the Policy Rules Management tab, select the rule you want to delete and click Delete.
- When prompted, confirm the delete action.
The CS configuration is modified. If the changes you made require you to restart the server, you will be prompted accordingly. Don't restart the server yet; you can do so after you've made all the required changes.
Adding New Policy Rules
Adding a policy rule to the CS configuration involves creating a new instance of an already registered policy plug-in module, assigning a unique name for the instance, and entering appropriate values for the parameters that define the module you want to create an instance of.
When you add a policy rule, the CS configuration gets updated with policy-specific information. Keep the following points in mind:
- When naming a policy instance (or rule), be sure to formulate the name using any combination of letters (aA to zZ), digits (0 to 9), an underscore (_), and a hyphen (-); other characters and spaces are not allowed. For example, you can type My_Policy_Rule or MyPolicyRule as the instance name, but not My Policy Rule.
- The status of the rule, enabled or disabled, depends on whether you check or deselect the enable parameter. A subsystem subjects certificate requests only to rules that are enabled.
- The server does not automatically reorder rules. Be sure to change the order of the rule, if required.
To add a new policy rule to the CS configuration:
The Select Policy Plugin Implementation window appears. It lists registered policy plug-in modules. If you have registered any custom policy modules (see "Registering a Policy Module" on page 541), they too will be listed here.
Reordering Policy Rules
For maintaining priority levels, CS supports a linear list of policy rules in increasing order of priority. This means that for a given policy category in the configuration file, a policy configuration with a lower priority precedes one with a higher priority. This simple linear listing avoids the need to have explicit locking on request attributes to prevent conflicting changes. By ordering the rules, you introduce a concurrency control whereby a higher-priority rule configuration overwrites any changes made by a lower-priority rule configuration that precedes it.
You may want to specify policies at different priority levels for the same operation depending on the end-entity information. For example, authentication policies, if any, need to precede others in the list.
To reorder policy rules in the CS configuration:
The Reorder Policy Rules window appears. It lists configured policy rules in the order in which they are executed by the subsystem.
- To change the order of a rule, select it in the list and click the Up or Down button, as appropriate.
Keep in mind that the server executes the rules on a first-come-first-served basis, overwriting the configuration determined by the previous rule, if any.
Testing Policy Configuration
To make sure that you've configured the server correctly, request a certificate and check the certificate for details such as for validity period, key type and size, and extensions.
Verify that the certificate contains the required details. Be sure to check the Extension section to see if it contains all the required extensions.
Using JavaScript for Policies
CS includes a facility for complex scripting of the policy plug-in instances via JavaScriptTM. Using the JavaScript policy processor allows you to:
- Determine the call sequence of existing Java plug-ins
- Use complex logic to determine whether to call a plug-in (versus the simpler predicates)
- Write policies in JavaScript
- Develop extensions without needing to know Java or have the Java SDK
CS uses the Rhino JavaScript engine from Mozilla.org. You can get more details about the Rhino project from this site:
To learn more about how to use JavaScript in CS, consult the sample policy.js file included in the distribution:
<server_root>/bin/cert/profiles/policy.js
Constraints-Specific Policy Module Reference
Constraints-specific policy plug-in modules help you define rules or constraints that CS uses to evaluate an incoming certificate enrollment, renewal, or revocation request. Each module enables you to configure the server to check the request for particular attributes, and, based on the configured criteria, either modify these attributes or reject the request altogether.
AttributePresentConstraints
The AttributePresentConstraints plug-in module enables you to configure the Certificate Manager and Registration Manager to reject a request if an LDAP attribute (for example, pin) is not present in the enrolling user's directory entry or if the attribute does not have a specified value.
If you enable the policy and configure it correctly, it first searches for the user under the base specified in the ldap.ldapconn.basedn parameter with the filter (uid=HTTP_PARAMS.UID) for the user's entry.
- If the value parameter is empty, the policy checks the attribute parameter:
- If the value parameter is not empty, the policy checks its value with the value of the attribute specified in the attribute parameter.
- In the case of multi-valued attributes, the request will be accepted if any of the values matches the specified value; comparisons are case sensitive.
Unlike some of the other policy modules, CS does not create an instance of the attribute present constraints policy during installation.
Table 12-3 describes the configuration parameters of the AttributePresentConstraints policy.
Table 12-3 AttributePresentConstraints Configuration Parameters
- BasicAuth specifies basic authentication (default). If you choose this option, be sure to enter the correct values for ldap.ldapauth.bindDN and password parameters; the plug-in uses the DN from the ldap.ldapauth.bindDN attribute to bind to the directory.
- SslClientAuth specifies SSL client authentication. If you choose this option, be sure to select the ldap.ldapconn.secureConn parameter and set the value of the ldap.ldapauth.clientCertNickname parameter to the nickname of the certificate to be used for SSL client authentication.
DSAKeyConstraints
The DSAKeyConstraints plug-in module imposes constraints on the following:
The policy restricts the key size to one of the sizes, such as 512 or 1024, supported by CS.
You may apply this policy to end-entity certificate enrollment and renewal requests. For example, if you want your CA to certify public keys up to 512 bits in length for end users and 1024 for servers, you can configure CS to do so using the policy.
During installation, CS automatically creates an instance of the DSA key constraints policy, named DSAKeyRule, that is enabled by default.
Table 12-4 describes the configuration parameters of the DSAKeyConstraints policy.
Table 12-4 DSAKeyConstraints Configuration Parameters
IssuerConstraints
The IssuerConstraints plug-in module enables you to effectively deploy certificate-based enrollment explained in "Certificate-Based Enrollment" on page 390.
The policy enables the Certificate Manager to authenticate an end user by checking the issuer DN of the CA that has issued the certificate the user presents as an enrollment token during enrollment. Note that in the current implementation, the CA that issues the new certificates must be the same as the one that has issued the certificates used for SSL client authentication; that is, the issuer DN in the authentication certificate must match the issuer DN specified in the policy configuration.
During installation, CS automatically creates an instance of the issuer constraints policy, named IssuerRule, that is disabled by default.
Table 12-5 describes the configuration parameters of the IssuerConstraints policy.
Table 12-5 IssuerConstraints Configuration Parameters
KeyAlgorithmConstraints
The KeyAlgorithmConstraints plug-in module restricts the key algorithm requested in certificates to the algorithms, such as RSA and DSA, supported by CS. In other words, this policy allows you to set restrictions on the types of public keys certified by CS.
You may apply this policy to end-entity certificate enrollment and renewal requests. For example, if you want your CA to certify only those public keys that comply with the PKCS-1 RSA Encryption Standard, you can configure the server for that using the policy.
During installation, CS automatically creates an instance of the key algorithm constraints policy, named KeyAlgRule, that is enabled by default.
Table 12-6 describes the configuration parameters of the KeyAlgorithmConstraints policy.
Table 12-6 KeyAlgorithmConstraints Configuration Parameters
RenewalConstraints
The RenewalConstraints plug-in module imposes constraints on renewal of expired certificates-it allows or restricts the server from renewing expired certificates. You may apply this policy to end-entity certificate renewal requests.
During installation, CS automatically creates an instance of the renewal constraints policy, named RenewalConstraintsRule, that is enabled by default.
Table 12-7 describes the configuration parameters of the RenewalConstraints policy.
Table 12-7 RenewalConstraints Configuration Parameters
RenewalValidityConstraints
The RenewalValidityConstraints plug-in module governs the formulation of content in the renewed certificate based on the currently issued certificate.
The renewal validity constraints policy enables you to enforce certain restrictions on certificate-renewal requests, when end entities attempt to renew their certificates.
During installation, CS automatically creates an instance of the renewal validity constraints policy, named DefaultRenewalValidityRule, that is enabled by default.
Table 12-8 describes the configuration parameters of the RenewalValidityConstraints policy.
Table 12-8 RenewalValidityConstraints Configuration Parameters
RevocationConstraints
The RevocationConstraints plug-in module imposes constraints on revocation of expired certificates-it allows or restricts the server from revoking expired certificates. You may apply this policy to end-entity certificate revocation requests.
During installation, CS automatically creates an instance of the revocation constraints policy, named RevocationConstraintsRule, that is enabled by default.
Table 12-9 describes the configuration parameters of the RevocationConstraints policy.
Table 12-9 RevocationConstraints Configuration Parameters
RSAKeyConstraints
The RSAKeyConstraints plug-in module imposes constraints on the following:
The policy restricts the key size to one of the sizes supported by CS-512, 1024, 2048, or 4096. In other words, the policy allows you to set up restrictions on the lengths of public keys certified by CS.
You may apply this policy to end-entity certificate enrollment and renewal requests. For example, if you want your CA to certify public keys up to 1024 bits in length for end users, you can configure the server accordingly using the policy.
During installation, CS automatically creates an instance of the RSA key constraints polic, named RSAKeyRule, that is disabled by default.
Table 12-10 describes the configuration parameters of the RSAKeyConstraints policy.
Table 12-10 RSAKeyConstraints Configuration Parameters
SigningAlgorithmConstraints
The SigningAlgorithmConstraints plug-in module restricts the requested signing algorithm to be one of the algorithms supported by CS: MD2 with RSA, MD5 with RSA, and SHA-1 with RSA, if the Certificate Manager's signing key is RSA and SHA-1 with DSA, if the Certificate Manager's signing key is DSA.
When a Certificate Manager digitally signs a message, it generates a compressed version of the message called a message digest. Some of the algorithms used to produce this digest include MD5 and SHA-1 (Secure Hash Algorithm).
- MD5 generates a 128-bit message digest. Most existing software applications that handle certificates only support MD5.
- SHA-1 generates a 160-bit message digest. Some software applications do not yet support the SHA-1 algorithm. For example, Netscape Navigator 3.0 (or higher) and Enterprise Server 2.01 (or higher) support SHA-1; previous versions of these applications do not support SHA-1.
You may apply this policy to end-entity certificate enrollment and renewal requests.
During installation, CS automatically creates an instance of the signing algorithm constraints policy, named SigningAlgRule, that is enabled by default.
Table 12-11 describes the configuration parameters of the SigningAlgorithmConstraints policy.
Table 12-11 SigningAlgorithmConstraintsConfiguration Parameters
SubCANameConstraints
The SubCANameConstraints plug-in module restricts a CA from issuing a subordinate CA certificate that has the same issuer name as that of the CA itself-that is, the policy prevents a situation where the signing certificates of a CA and its subordinate CA have identical issuer names.
This policy must be turned on if you're planning to issue subordinate CA certificates. Whenever the Certificate Manager issues a certificate, it stores the related information in its internal database; if the CA issues a subordinate CA certificate with an issuer DN that matches its own issuer DN, the internal database will not function properly.
You may apply this policy to CA certificate enrollment and renewal requests.
During installation, CS automatically creates an instance of the subordinate CA name constraints policy, named SubCANameConstraints, that is enabled by default.
Table 12-12 describes the configuration parameters of the SubCANameConstraints policy.
Table 12-12 SubCANameConstraints Configuration Parameters
UniqueSubjectNameConstraints
The UniqueSubjectNameConstraints plug-in module restricts the server from issuing multiple certificates with same subject names. Optionally, you can also configure the server to allow multiple certificates with the same subject name if the key usages are different. Note that key usages for certificates are usually specified by the key usage extension and CS allows you to add this extension to certificates using the key usage extension policy explained in "KeyUsageExt" on page 513.
You may apply the unique subject name constraints policy to end-entity certificate enrollment and renewal requests. For example, if you want to prevent your users from requesting multiple certificates with same subject names, you can configure the server accordingly using the policy. Alternatively, if you want to allow your users to own multiple certificates, each for a different use, all having the same subject name, you can do so easily using the enableKeyUsageExtensionChecking parameter defined in this policy. This parameter makes the server check whether the key usages specified in the certificate request being processed is different than those specified in the existing certificates that have the same subject names and accordingly issue or deny the certificate. Keep in mind that the server can check for key usages only if the key usage extension bits are set in the certificate request being processed as well as in the existing certificates that have the same subject names.
During installation, CS automatically creates an instance of the unique subject name constraints policy, named UniqueSubjectNameConstraints, that is disabled by default.
Table 12-13 describes the configuration parameters of the UniqueSubjectNameConstraints policy.
Table 12-13 UniqueSubjectNameConstraints Configuration Parameters
- Select if you want the server to check the certificate request for the subject name uniqueness as soon as the user submits it.
- Deselect if you want the server to check the certificate request for the subject name uniqueness after agent approval; that is, you want the policy to be applied to the request after an agent approves the request. You should choose this option if you want the server to check the Key Usage extension (see "KeyUsageExt" on page 513) before determining whether to issue the certificate.
- Select if you want the server to check the certificate request for the Key Usage extension. If you select, the server checks its internal database for certificates that have the same subject name as the one specified in the request. For each certificate that has the matching subject name, the server compares the Key Usage extension of the certificate to the one specified in the request. If the server finds a certificate that has the same subject name and Key Usage extension, it rejects request. Otherwise, the server approves the request. (This choice is suitable if you want to have multiple certificates with same subject names but for different purposes, such as signing and encrypting. If key-usage comparison is to be done, be sure to specify that this policy is to be applied after the Key Usage extension policy.
- Deselect if you don't want the server to check the certificate request for the Key Usage extension. If you deselect, the server does not compare the Key Usage extension in the request with the ones set in the existing certificates that have the same subject name; it simply rejects requests with same subject names.
ValidityConstraints
The ValidityConstraints plug-in module enforces minimum and maximum validity periods for certificates and changes them if the policy is not met. Specifically, the policy imposes constraints on the following:
- The duration of a certificate's validity period (based on supported minimum and maximum validity periods).
- The lead and lag time for the beginning date and time (the notBefore and notAfter attributes in certificate requests) for the validity period; how far back into the front or back the notBefore date could go in minutes.
If this policy rule is enabled, the server applies the rule to the certificate request being processed, and then determines if the validity period in the request is acceptable. The rule checks two X.509 attributes of the certificate, the notBefore and notAfter time, which together indicate the total validity life of a certificate, to make sure that they conform to the configured ranges.
The rule checks that the value of the notBefore attribute in the request is not more than leadTime minutes in the future; the leadTime is a configurable parameter in the plug-in implementation. The ability to configure the value of the leadTime parameter in the policy rule allows you to prohibit end entities from requesting certificates whose validity starts too far in the future, and yet allows some amount of toleration of clock-skew problems. For example, if the current date and time is 01/15/2000 (mm/dd/YYYY) and 1:30 p.m., the value of the notBefore attribute is set to 3:00 p.m., and that the leadTime is 10 minutes, then the request would fail, because the validity requested begins more than 10 minutes in the future.
The rule also checks that the value of the notBefore attribute in the request is not more than lagTime minutes in the past. For example, if the current date and time is 01/15/2000 (mm/dd/yyyy) and 1:30 p.m., the value of the notBefore attribute is set to 1:15 p.m., and the lagTime is set to 10 minutes, the request would fail because the user has requested a certificate 15 minutes in the past. Note that a request with notBefore set to 1:25 p.m. would have passed, however.
You may apply this policy to end-entity certificate enrollment requests.
During installation, CS automatically creates an instance of the validity constraints policy, named DefaultValidityRule, that is enabled by default.
Table 12-14 describes the configuration parameters of the ValidityConstraints policy.
Table 12-14 ValidityConstraints Configuration Parameters
Extension-Specific Policy Module Reference
To enable you to add standard and private extensions to end-entity certificates, CS provides a set of policy plug-in modules; each module enables you to add a particular extension to a certificate request.
When deciding whether to add any of the X.509 v3 certificate extensions, keep in mind that not all applications support X.509 v3 extensions. Among the applications that do support extensions, not all applications will recognize every extension.
You can use these modules to configure a Certificate Manager and Registration Manager to add extensions to certificates. Both subsystems add extensions to a certificate request when it undergoes policy processing. Keep in mind that the changes made to a request by a Registration Manager may be overwritten by a Certificate Manager when it subjects the request to its own policy checks.
In general, you should make custom extensions noncritical if you want your certificates supported by other applications. (Other applications most likely will not understand your extension.)
By default, only noncritical extensions are added to certificates. This ensures that the resulting certificates can be used with all clients. If you add a critical extension, the resulting certificate can only be used by clients that support that extension.
Additionally, the server also provides a module for adding any custom, ASN.1 type extensions. If you determine that the default policy modules do not meet your requirements entirely, you can develop a custom module using CS SDK.
AuthInfoAccessExt
The AuthInfoAccessExt plug-in module enables you to add the Authority Information Access Extension. The 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 "CRLDistributionPointsExt" on page 501 allows you to reference to CRL locations.
For general information about this extension, see "authorityInfoAccess" on page 731.
During installation, CS automatically creates an instance of the authority information access extension policy, named AuthInfoAccessExt, that is disabled by default.
Note that if you installed the Certificate Manager with it's built-in OCSP service enabled, the policy rule will be enabled and the address location (ad0_location=) will be pointed to the Certificate Manager's non-SSL end-entity port. For example, if the non-SSL end-entity port of your Certificate Manager is 80, the URL would look like this: http://ocspResponder.example.com:80/ocsp
Table 12-15 AuthInfoAccessExt Configuration Parameters
- If you selected dNSName, the value must be a valid domain name in the preferred-name syntax. You may use upper and lower case letters in the domain name; no significance is attached to the case. Do not use the string " " for the DNS name. Also don't use the DNS representation for Internet mail addresses. For example, ocspResponder.example.com.
- If you selected URL, the value must be a non-relative universal resource identifier (URI) following the URL syntax and encoding rules. That is, the name must include both a scheme (for example, http) and a fully qualified domain name or IP address of the host. For example, http://ocspResponder.example.com:8000
- If you selected iPAddress, the value must be a valid IP address specified in dot-separated numeric component notation. The syntax for specifying the IP address is as follows:
IPv4 address must be in the n.n.n.n format; for example, 128.21.39.40. IPv4 address with netmask must be in the n.n.n.n,m.m.m.m format. For example, 128.21.39.40,255.255.255.00.
For IP version 6 (IPv6), the address should be in the form with netmask separated by a comma. Examples of IPv6 addresses with no netmask are 0:0:0:0:0:0:13.1.68.3 and FF01::43. Examples of IPv6 addresses with netmask are 0:0:0:0:0:0:13.1.68.3,FFFF:FFFF:FFFF:FFFF:FFFF:
FFFF:255.255.255.0 and FF01::43,FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FF00:0000.
- If you selected OID, the value must be a unique, valid OID specified in dot-separated numeric component notation. 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 <<<XREF Appendix B, "Object Identifiers">>> for information on allocating private OIDs. For example, 1.2.3.4.55.6.5.99.
AuthorityKeyIdentifierExt
The AuthorityKeyIdentifierExt plug-in module enables you to add the Authority Key Identifier Extension to certificates. 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.
For information on setting the subject key identifier extension in certificates, see "SubjectKeyIdentifierExt" on page 540.
During installation, CS automatically creates an instance of the authority key identifier extension policy, named AuthorityKeyIdentifierExt, that is enabled by default.
Table 12-16 AuthorityKeyIdentifierExt Configuration Parameters
BasicConstraintsExt
The BasicConstraintsExt plug-in module enables you to add the Basic Constraints Extension in certificates. The extension identifies whether 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.
During installation, CS automatically creates an instance of the basic constraints extension policy, named BasicConstraintsExt, that is enabled by default.
Table 12-17 BasicConstraintsExt Configuration Parameters
- If you leave the field blank, the path length defaults to a value that is determined by the path length set on the Basic Constraints extension in the issuer's certificate. If the issuer's path length is unlimited, the path length in the subordinate CA certificate will also be unlimited. If the issuer's path length is an integer greater than zero, the path length in the subordinate CA certificate will be set to a value that's one less than the issuer's path length; for example, if the issuer's path length is 4, the path length in the subordinate CA certificate will be set to 3.
CertificatePoliciesExt
The CertificatePoliciesExt plug-in module enables you to add the Certificate Policies Extension in certificates. The extension contains a sequence of one or more policy statements, each indicating the policy under which the certificate has been issued and identifying the purposes for which the certificate may be used. Presence of this extension in certificates enables an application with specific policy requirements to compare its list of policies to the ones contained in a certificate during its validation; typically, such applications will have a list of policies (which they will accept) and compare the policies in the certificate to their list as a part validating the certificate.
For general information about this extension, see "certificatePolicies" on page 733.
During installation, CS automatically creates an instance of the certificate policies extension policy, named CertificatePoliciesExt, that is disabled by default.
Table 12-18 CertificatePoliciesExt Configuration Parameters
ltd. (c) 2002 Example Corporation
CertificateRenewalWindowExt
The CertificateRenewalWindowExt plug-in module enables you to add the Certificate Renewal Window Extension to certificates. The extension aids in managing the life cycle of a certificate by specifying a process to follow for renewing a certificate and by defining a time window when automatic renewal of the certificate should be attempted.
Because the renewal process requires end users to remember when their certificates expire and renew them before the expiry date, some clients provide built-in support for automated renewal. Inclusion of the certificate renewal window extension in certificates is useful in a PKI setup with such clients.
Unlike some of the other policy modules, CS does not create an instance of the certificate renewal window extension policy during installation. If you want the server to add this extension to certificates, you must create an instance of the CertificateRenewalWindowExt module and configure it.
Table 12-19 CertificateRenewalWindowExt Configuration Parameters
- n specifies a future time for certificate renewal; the beginTime field of the extension will be set to the specified time since certificate issuance. You can specify the time period in seconds, minutes, hours, days, or months. Use the following suffixes to indicate the time unit.
s - seconds
m - minutes
h - hours
D - days
M - months
For example, if you're issuing certificates with a validity period of two years and want the renewal window to begin a month before the certificates expire, and want to specify the interval in months, you would enter 23M in this field. To specify the same validity interval in seconds, you would set the value to 59616000s (23 months x 30 days x 24 hours x 60 minutes x 60 seconds).
- n specifies a past or future time, in seconds, by which the certificate must be renewed; the endTime field of the extension will be set to the specified time since certificate issuance. You can specify the time period in seconds, minutes, hours, days, or months. Use the following suffixes to indicate the time unit.
s - seconds
m - minutes
h - hours
D - days
M - months
CertificateScopeOfUseExt
The CertificateScopeOfUseExt plug-in module enables you to add the Certificate Scope of Use Extension to certificates. The extension enables you to specify a list of web sites that may request the use of a particular certificate for SSL client authentication, thus aiding certificate-using applications to select certificates to present to web sites and to control release of these certificates.
The SSL protocol provides a way for a client application to authenticate itself to a web site or server. SSL client authentication occurs upon request of the server, and proceeds by providing a certificate and a signature to the server. The client may have more than one certificate that could be used to perform this authentication. The SSL protocol provides a way for the server to indicate which certificate may be useful by listing issuing CAs in one of the SSL protocol messages.
By using a particular certificate for SSL client authentication, the client releases information about itself to the server. This information may include the name and key information contained in the certificate. It also releases the information that the client holds a certificate from a particular CA. This information may be of interest to the company running the server, for example to find users that have certificates from competing companies.
The certificate scope of use extension can be included in certificates to restrict the scope-of-use of the certificate for client authentication; the extension enables the certificate-using application to restrict the release of individual certificates to web sites requesting SSL client authentication.
The certificate scope of use extension policy in CS enables you to include a list of name patterns that will match server DNS names where the certificate may be used. It's up to the certificate-using applications to use the values in this extension to filter the list of potential certificates to use for client authentication.
Unlike some of the other policy modules, CS does not create an instance of the certificate scope of use extension policy during installation. If you want the server to add this extension to certificates, you must create an instance of the CertificateScopeOfUseExt module and configure it.
Table 12-20 CertificateScopeOfUseExt Configuration Parameters
- If you selected dNSName, the value must be a valid domain name. You may use upper and lower case letters in the domain name; no significance is attached to the case. Do not use the string " " for the DNS name. Also don't use the DNS representation for Internet mail addresses; such identities should be encoded as rfc822Name. For example, webSite.example.com.
- If you selected iPAddress, the value must be a valid IP address specified in dot-separated numeric component notation. The syntax for specifying the IP address is as follows:
IPv4 address must be in the n.n.n.n format; for example, 128.21.39.40. IPv4 address with netmask must be in the n.n.n.n,m.m.m.m format. For example, 128.21.39.40,255.255.255.00.
For IP version 6 (IPv6), the address should be in the form with netmask separated by a comma. Examples of IPv6 addresses with no netmask are 0:0:0:0:0:0:13.1.68.3 and FF01::43. Examples of IPv6 addresses with netmask are 0:0:0:0:0:0:13.1.68.3,FFFF:FFFF:FFFF:FFFF:FFFF:
FFFF:255.255.255.0 and FF01::43,FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FF00:0000.
- If you selected OID, the value must be a unique, valid OID specified in dot-separated numeric component notation. 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. For example, 1.2.3.4.55.6.5.99.
number
CRLDistributionPointsExt
The CRLDistributionPointsExt plug-in module enables you to add the CRL Distribution Points Extension to certificates. This extension, when present in a certificate, identifies one or more locations from where the 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.
During installation, CS automatically creates an instance of the CRL distribution points extension policy, named CRLDistributionPointsExt, that is disabled by default.
Table 12-21 CRLDistributionPointsExt Configuration Parameters
- An X.500 directory name in the RFC 2253 syntax. For example, the name would look similar to the subject name in a certificate, like this: CN=CA Central, OU=Research Dept, O=Example Corporation, C=US
- A URI; for example, it would look similar to this:
http://testCA.example.com:80- An RDN which specifies a location relative to the CRL Issuer. In this case, the value of the pointType attribute must be RelativeToIssuer.
ExtendedKeyUsageExt
The ExtendedKeyUsageExt plug-in module enables you to add the Extended Key Usage Extension to certificates. 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. (For information on key usage extension, see "KeyUsageExt" on page 513.)
For general information about this extension, see "extKeyUsage" on page 734.
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.
During installation, CS automatically creates two instances of the extended key usage extension policy, named CODESigningExt for object signing certificates and OCSPSigningExt for an OCSP responder certificate, both are enabled by default.
Note that the CODESigningExt policy rule must remain enabled if you want CS to issue object signing certificates with the correct extended key usage extension.
Note that the OCSPSigningExt policy rule must remain enabled if your PKI setup includes a CA-delegated OCSP responder and you want to issue an OCSP responder certificate to that server; the rule adds the extended key usage extension to an OCSP responder certificate indicating that the associated key can be used for signing OCSP responses.
Table 12-23 ExtendedKeyUsageExt Configuration Parameters
GenericASN1Ext
The GenericASN1Ext plug-in module enables you to add custom extensions to certificates. Using this policy, you can add as many ASN.1 type based-extensions as required without having to write any code. Further, it eliminates the dependency on the command-line tools for generating base-64 encoded standard extensions from the x.509 extension classes.
The generic extension policy in CS accepts custom extensions in the form of object identifiers (OIDs) and values as DER-encoded extension values. That is, for the server to add a custom extension to certificates it issues, you need to first define the extension and then configure the server with extension details.
Similar to a standard extension, you define a custom extension by defining an OID and a ASN.1 structure.
- The OID must be specified in the dot-separated numeric component notation (for example, 2.5.29.35). Although you can invent your own OIDs for the purposes of evaluating and testing the 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.
- The ASN.1 structure must be constructed from a sequence of DER-encoded extension values.
The resulting extension would look similar to the way a standard extension appears in certificates (as defined in RFC 2459):
Extension ::= SEQUENCE { extnID OBJECT IDENTIFIER, critical BOOLEAN DEFAULT FALSE, extnValue OCTET STRING }In the policy configuration, the extnID field is defined by the oid parameter, the critical field is defined by the critical parameter, and the extnValue field is defined by evaluating the expression in the pattern parameter, which in turn is defined by the attribute parameters. See Table 12-24 on page 507 for details on individual parameters.
Typically, the application receiving the certificate checks the extension ID to determine if it can recognize the ID. If it can, it uses the extension ID to determine the type of value used. When adding your custom extension to certificates, keep in mind that if the extension exists in a certificate and if it is marked critical, the application validating the certificate must be able to interpret the extension, or else it must reject the certificate. Since it's unlikely that all applications will be able to interpret your custom extensions, you should consider marking these extensions noncritical.
Note that each instance of the policy can be configured to add one custom extension only. To configure the server to add multiple custom extensions, create multiple instances of the module, each with a distinct name and appropriate configuration values. Also note that the policy allows you to encode simple (possibly nested) SEQUENCEs. There is no support for CHOICE, SET, or ASN.1 tagging.
During installation, CS automatically creates an instance of the generic ASN.1 extension policy, named GenericASN1Ext, that is disabled by default.
Configuration Parameters of GenericASN1Ext
The configuration defines a custom extension named testGenASN1Ext with OID 2.4.5.99. The extension is non-critical, and it will be added to all certificates issued by the server. The expected dumpasn1 output (see "dumpasn1 Tool" in CS Command-Line Tools Guide) of the resulting extension, would look like this:
337 30 148: . . . . SEQUENCE { 340 06 3: . . . . . OBJECT IDENTIFIER '2 4 5 99' 345 04 140: . . . . . OCTET STRING, encapsulates { 348 30 137: . . . . . . . SEQUENCE { 351 13 24: . . . . . . . . PrintableString '1st data in 1st sequence' 377 16 24: . . . . . . . . IA5String '2nd data in 1st sequence' 403 13 32: . . . . . . . . PrintableString 'This is 3rd data in 1st sequence' 437 04 10: . . . . . . . . OCTET STRING : . . . . . . . . . 11 22 33 44 A0 B0 C0 D0 E0 F0 449 30 37: . . . . . . . . SEQUENCE { 451 17 13: . . . . . . . . . UTCTime '000406070000Z' 466 30 8: . . . . . . . . . SEQUENCE { 468 01 1: . . . . . . . . . . BOOLEAN TRUE 471 06 3: . . . . . . . . . . OBJECT IDENTIFIER '2 4 5 100' : . . . . . . . . . . } 476 04 10: . . . . . . . . . OCTET STRING : . . . . . . . . . 11 22 33 44 A0 B0 C0 D0 E0 F0 : . . . . . . . . . } : . . . . . . . . } : . . . . . . . } : . . . . . }
Table 12-24 GenericASN1Ext Configuration Parameters
- Each data component in the pattern must be represented by it's predefined attribute identifier, 0 to 9, and each sequence must be grouped by a pair of curly brackets, {}.
- Each attribute identifier represented in the pattern must be fully defined in the extension. For example, if you want to include attribute identifier 0, you must specify values for attribure.0.type, attribure.0.source, and attribure.0.value parameters.
No default value is assigned to this parameter.Example: {{012}34}
- Select OctetString for extensions that have ASN.1 OCTET STRING values. It's case insensitive and the value is dependent on data source. If the data source is Value, the value must be in colon-separated, ASCII hexadecimal encoding notation. If the data source is File, the server reads the attribute value from the file specified.
- If the data type is OctetString and if the data source is Value, enter the value in colon-separated ASCII hexadecimal encoding notation. For example, 11:22:33:44:A0:B0:C0:D0:E0:F0.
If data source is File, enter the complete file path, including the filename, in the specified format; for example, /usr/customExt/octet_string_value.txt. When specifying file path in a Windows NT system do not use the NT native file separator, the backward slash (\). Use Unix style file separator, the forward slash (/), instead.
IssuerAltNameExt
The IssuerAltNameExt plug-in module enables you to add the Issuer Alternative Name Extension defined in X.509 and PKIX standard RFC 2459 (see http://www.ietf.org/rfc/rfc2459.txt) to certificates. This extension enables binding of or associating Internet style identities-such as Internet electronic mail address, a DNS name, an IP address, and a uniform resource indicator (URI)- with the certificate issuer.
For general information about this extension, see "issuerAltName" on page 735.
Unlike some of the other policy modules, CS does not create an instance of the issuer alternative name extension policy during installation. If you want the server to add this extension to certificates, you must create an instance of the IssuerAltNameExt module and configure it. For instructions, see section "Step 4. Add New Policy Rules" in Chapter 18, "Setting Up Policies" of CS Administrator's Guide.
Table 12-25 IssuerAltNameExt Configuration Parameters
- 0 specifies that no identities can be contained in the extension (default).
- n specifies the total number of identities to be included in the extension; it must be an integer greater than zero. The default value is 8.
Example: 2
- If you selected rfc822Name, the value must be a valid Internet mail address in the local-part@domain format; see the definition of an rfc822Name as defined in RFC 822 (http://www.ietf.org/rfc/rfc0822.txt). You may use upper and lower case letters in the mail address; no significance is attached to the case. For example, testCA@example.com.
- If you selected dNSName, the value must be a valid domain name in the preferred-name syntax as specified by RFC 1034 (http://www.ietf.org/rfc/rfc1034.txt). You may use upper and lower case letters in the domain name; no significance is attached to the case. Do not use the string " " for the DNS name. Also don't use the DNS representation for Internet mail addresses; such identities should be encoded as rfc822Name. For example, testCA.example.com.
- If you selected URL, the value must be a non-relative universal resource identifier (URI) following the URL syntax and encoding rules specified in RFC 1738. That is, the name must include both a scheme (for example, http) and a fully qualified domain name or IP address of the host. For example, http://testCA.example.com.
- If you selected iPAddress, the value must be a valid IP address (IPv4 or IPv6) specified in dot-separated numeric component notation. The syntax for specifying the IP address is as follows:
For IP version 4 (IPv4), the address should be in the form specified in RFC 791 (http://www.ietf.org/rfc/rfc0791.txt). IPv4 address must be in the n.n.n.n format; for example, 128.21.39.40. IPv4 address with netmask must be in the n.n.n.n,m.m.m.m format. For example, 128.21.39.40,255.255.255.00.
For IP version 6 (IPv6), the address should be in the form described in RFC 1884 (http://www.ietf.org/rfc/rfc1884.txt), with netmask separated by a comma. Examples of IPv6 addresses with no netmask are 0:0:0:0:0:0:13.1.68.3 and FF01::43. Examples of IPv6 addresses with netmask are 0:0:0:0:0:0:13.1.68.3,FFFF:
FFFF:FFFF:FFFF:FFFF:FFFF:255.255.255.0 and FF01::43,FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FF00:0000.
- If you selected OID, the value must be a unique, valid OID specified in the dot-separated numeric component notation. 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. For example, 1.2.3.4.55.6.5.99.
KeyUsageExt
The KeyUsageExt plug-in module enables you to add the Key Usage Extension to certificates. 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.
The key usage extension is a string of boolean bit-flags, each bit identifying the purpose for which a key is to be used. Table 12-26 lists the bits and their designated purposes.
You can restrict the purposes for which a key pair (and thus the corresponding certificate) should be used by setting the appropriate key-usage bits. For example, if you want to restrict a key pair to be used for digital signature only, when issuing the certificate you would add the key usage extension to the certificate with digital_signature bit (or bit 0) set.
Note that you can specify which bits in the extension are to be set on both server and client sides:
- On the server side, you set the bits by modifying the appropriate configuration parameters that are defined in the key usage extension policy.
- On the client side, bits set in the key usage extension are formed from pre-defined HTTP input variables that can be embedded as hidden values in the enrollment forms. You specify which bits are to be set by adding the appropriate HTTP variables to the enrollment forms. Table 12-27 lists the HTTP input variables that correspond to key usage extension bits.
The default enrollment forms provided for requesting various types of certificates include the appropriate HTTP input variables that correspond to the key-usage bits. By default only variables that correspond to key-usage bits that need to be set are included in the form.
Typically, you won't have to change the key-usage bit setting by editing the enrollment forms as you can do this easily by making the appropriate changes to the policy instance (bits set on the server side override the ones set on the client side). However, if you want to add new variables on the client side, you can do that too. Be sure to add the new variable in the following format:
For all certificates, the key-usage-bits set on the server side (which is governed by the policy) override the ones set on the client side.
During installation, CS automatically creates multiple instances of the key usage extension policy suitable for various types of certificates that you may want the server to issue. The default instances are named as follows:
- CMCertKeyUsageExt This rule is for setting the appropriate key-usage bits in Certificate Manager CA signing certificates and is enabled by default.
The server is configured to set digitalSignature, nonRepudiation, keyCertsign, and cRLSign bits in CA signing certificates. Notice that the key-usage bits specified in the default policy rule match the bits specified in the enrollment form (ManCAEnroll.html) for requesting CA signing certificates.
- RMCertKeyUsageExt This rule is for setting the appropriate key-usage bits in Registration Managers' signing certificates and is enabled by defualt.
The server is configured to set digitalSignature and nonRepudiation bits in Registration Manager signing certificates. Notice that the key-usage bits specified in the default policy rule match the bits specified in the enrollment form (ManRAEnroll.html) for requesting Registration Manager signing certificates.
- ServerCertKeyUsageExt This rule is for setting the appropriate key-usage bits in SSL server certificates and is enabled by default.
The server is configured to set digitalSignature, nonRepudiation, keyEncipherment, and dataEncipherment bits in SSL server certificates. Notice that the key-usage bits specified in the default policy rule match the bits specified in the enrollment form (ManServerEnroll.html) for requesting SSL server certificates.
- ClientCertKeyUsageExt This rule is for setting the appropriate key-usage bits in SSL client certificates and is enabled by default.
- ObjSignCertKeyUsageExt This rule is for setting the appropriate key-usage bits in object signing certificates and is enabled by default.
The server is configured to set digitalSignature and keyCertsign bits in object-signing certificates. Notice that the key-usage bits specified in the default policy rule match the bits specified in the enrollment form (ManObjSignEnroll.html) for requesting object-signing certificates.
- CRLSignCertKeyUsageExt This rule is for setting the appropriate key-usage bits in a CRL signing certificate and is enabled by default.
The value of an HTTP input variable corresponding to a key-usage bit must be either true or false; any other value is considered equivalent to false. For example, a value tree would be interpreted as false by the server. Note that values true and false are case insensitive.
NameConstraintsExt
The NameConstraintsExt plug-in module enables you to add the Name Constraints Extension to certificates. 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.
During installation, CS automatically creates an instance of the name constraints extension policy, named NameConstraintsExt, that is disabled by default.
Table 12-29 NameConstraintsExt Configuration Parameters
base.generalNameChoice
- Select rfc822Name if the subtree is an Internet mail address (default).
- Select directoryName if the subtree is an X.500 directory name.
- Select dNSName if the subtree is a DNS name.
- Select ediPartyName if the subtree is a EDI party name.
- Select URL if the subtree is a uniform resource locator.
- Select iPAddress if the subtree is an IP address.
- Select OID if the subtree is an object identifier.
- Select otherName if the subtree is in any other name form.
Example: directoryName
base.generalNameValue
- If you selected rfc822Name, the value must be a valid Internet mail address in the local-part@domain format; see the definition of an rfc822Name as defined in RFC 822 (http://www.ietf.org/rfc/rfc0822.txt). You may use upper and lower case letters in the mail address; no significance is attached to the case. For example, testCA@example.com.
- If you selected dNSName, the value must be a valid domain name in the preferred-name syntax as specified by RFC 1034 (http://www.ietf.org/rfc/rfc1034.txt). You may use upper and lower case letters in the domain name; no significance is attached to the case. Do not use the string " " for the DNS name. Also don't use the DNS representation for Internet mail addresses; such identities should be encoded as rfc822Name. For example, testCA.example.com.
- If you selected URL, the value must be a non-relative universal resource identifier (URI) following the URL syntax and encoding rules specified in RFC 1738. That is, the name must include both a scheme (for example, http) and a fully qualified domain name or IP address of the host. For example, http://testCA.example.com.
- If you selected iPAddress, the value must be a valid IP address (IPv4 or IPv6) specified in the dot-separated numeric component notation. The syntax for specifying the IP address is as follows:
For IP version 4 (IPv4), the address should be in the form specified in RFC 791 (http://www.ietf.org/rfc/rfc0791.txt). IPv4 address must be in the n.n.n.n format; for example, 128.21.39.40. IPv4 address with netmask must be in the n.n.n.n,m.m.m.m format. For example, 128.21.39.40,255.255.255.00.
For IP version 6 (IPv6), the address should be in the form described in RFC 1884 (http://www.ietf.org/rfc/rfc1884.txt), with netmask separated by a comma. Examples of IPv6 addresses with no netmask are 0:0:0:0:0:0:13.1.68.3 and FF01::43. Examples of IPv6 addresses with netmask are 0:0:0:0:0:0:13.1.68.3,FFFF:
FFFF:FFFF:FFFF:FFFF:FFFF:255.255.255.0 and FF01::43,FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FF00:0000.
- If you selected OID, the value must be a unique, valid OID specified in dot-separated numeric component notation. 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. For example, 1.2.3.4.55.6.5.99.
min
max
base.generalNameChoice
- Select rfc822Name if the subtree is an Internet mail address.
- Select directoryName if the subtree is an X.500 directory name.
- Select dNSName if the subtree is a DNS name.
- Select ediPartyName if the subtree is a EDI party name.
- Select URL if the subtree is a uniform resource locator.
- Select iPAddress if the subtree is an IP address.
- Select OID if the subtree is an object identifier.
- Select otherName if the subtree is in any other name form.
base.generalNameValue
- If you selected rfc822Name, the value must be a valid Internet mail address in the local-part@domain format; see the definition of an rfc822Name as defined in RFC 822 (http://www.ietf.org/rfc/rfc0822.txt). You may use upper and lower case letters in the mail address; no significance is attached to the case. For example, testCA@example.com.
- If you selected dNSName, the value must be a valid domain name in the preferred-name syntax as specified by RFC 1034 (http://www.ietf.org/rfc/rfc1034.txt). You may use upper and lower case letters in the domain name; no significance is attached to the case. Do not use the string " " for the DNS name. Also don't use the DNS representation for Internet mail addresses; such identities should be encoded as rfc822Name. For example, testCA.example.com.
- If you selected URL, the value must be a non-relative universal resource identifier (URI) following the URL syntax and encoding rules specified in RFC 1738. That is, the name must include both a scheme (for example, http) and a fully qualified domain name or IP address of the host. For example, http://testCA.example.com.
- If you selected iPAddress, the value must be a valid IP address (IPv4 or IPv6) specified in the dot-separated numeric component notation. The syntax for specifying the IP address is as follows:
For IP version 4 (IPv4), the address should be in the form specified in RFC 791 (http://www.ietf.org/rfc/rfc0791.txt). IPv4 address must be in the n.n.n.n format; for example, 128.21.39.40. IPv4 address with netmask must be in the n.n.n.n,m.m.m.m format. For example, 128.21.39.40,255.255.255.00.
For IP version 6 (IPv6), the address should be in the form described in RFC 1884 (http://www.ietf.org/rfc/rfc1884.txt), with netmask separated by a comma. Examples of IPv6 addresses with no netmask are 0:0:0:0:0:0:13.1.68.3 and FF01::43. Examples of IPv6 addresses with netmask are 0:0:0:0:0:0:13.1.68.3,FFFF:
FFFF:FFFF:FFFF:FFFF:FFFF:255.255.255.0 and FF01::43,FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FF00:0000.
min
max
NSCCommentExt
The NSCCommentExt plug-in module enables you to add the Netscape Certificate Comment Extension to certificates. The extension can be used to include textual comments in certificates. Applications that are capable of interpreting the comment may display it to a relying party when the certificate is used or viewed.
For general information about this extension, see "netscape-comment" on page 749.
During installation, CS automatically creates an instance of the Netscape certificate comment extension policy, named NSCCommentExt, that is disabled by default.
NSCertTypeExt
The NSCertTypeExt plug-in module enables you to add the Netscape Certificate Type extension to certificates. The extension identifies the certificate type-for example, it identifies whether the certificate is a CA certificate, server SSL certificate, client SSL certificate, object signing certificate, or S/MIME certificate-and thus enables you to restrict the usage of a certificate to predetermined purposes.
- If the extension exists in a certificate, it limits the uses of the certificate to those specified (it limits the applications for a certificate).
- If the extension is not present, the certificate can be used for all applications except object signing.
The Netscape certificate type extension is a string of boolean bit-flags, each bit identifying the purpose for which a certificate to be used. Table 12-31 lists the bits and their designated purposes. The extension has no default value.
The Netscape certificate type extension policy has been implemented in such a way that it enables you to set the appropriate certificate-type bits for certificates being issued by CS. This way, you can restrict the purposes for which a certificate should be used by adding the extension, with the appropriate bits set, to the certificate at the time of issuance. For example, if you want to restrict a certificate to be used for SSL client authentication only, when issuing the certificate you would add the Netscape certificate type extension to the certificate with ssl_client (bit 0) set. For general guidelines on setting the Netscape certificate type extension, see "netscape-cert-type" on page 748.
In the current implementation, you can specify whether to add the extension to certificates on the server side and which bits in the extension are to be set on the client side-you specify whether to add the extension by enabling the Netscape certificate type extension policy and which bits are to be set by adding the appropriate HTTP variables to the enrollment forms.
Bits set in the Netscape certificate type extension are formed from pre-defined input variables that you can embed as hidden values in the default enrollment forms. Table 12-32 lists the HTTP input variables that correspond to Netscape certificate type extension bits.
During installation, CS automatically creates an instance of the Netscape certificate type extension policy for the various types of certificates that you may want the server to issue, named NSCertTypeExt, that is enabled by default.
Additionally, the default enrollment forms-the directory-based, directory- and PIN-based, manual, and Kerberos server-based enrollment forms-for various types of certificates also include the appropriate HTTP input variables corresponding to Netscape certificate type extension bits. For details about these forms.
Note that the default enrollment forms embed variables that are considered appropriate for the type of certificate, such as client, server, or CA, that can be requested using the form. For example, the server enrollment form embeds the ssl_server variable, whereas the subordinate CA (Certificate Manager) enrollment form embeds the ssl_client, email_ca, ssl_ca and object_signing_ca variables.
In general, the forms are set up so that you don't have to make any modifications. However, if there is a need to modify the bit settings, be sure to add or remove the corresponding variable. Also, when adding a new variable, make sure that the HTML input format is as follows:
<input type="HIDDEN" value="true" name="variable_name">
where variable_name can be any of the variables listed in Table 12-32.
Table 12-33 NSCertTypeExt Configuration Parameters
- Select if you want the server to add the extension, with default bits, to certificates. If you select and if no bits are requested from the HTTP input, the server adds the Netscape certificate type extension to certificates with the following bits set:
- ssl client (bit 0)
- email (bit 2)- Deselect if you don't want the server to add the extension with default bits. If you deselect and if no bits are requested from the HTTP input, the server does not add the extension to certificates.
OCSPNoCheckExt
The OCSPNoCheckExt plug-in module enables you to add the OCSP No Check Extension to certificates. The extension, which should be used in OCSP responder certificates only, indicates how OCSP-compliant applications can verify the revocation status of the certificate an authorized OCSP responder uses to sign OCSP responses.
For general information about this extension, see "OCSPNocheck" on page 738.
During installation, CS automatically creates an instance of the OCSP no check extension policy, named OCSPNoCheckExt, that is enabled by default.
Table 12-34 OCSPNoCheckExt Configuration Parameters
PolicyConstraintsExt
The PolicyConstraintsExt plug-in module enables you to add the Policy Constraints Extension to certificates. The extension, which can be used in CA certificates only, constrains path validation in two ways-either to prohibit policy mapping or to require that each certificate in a path contain an acceptable policy identifier. The policy allows you to specify both, requireExplicitPolicy and inhibitPolicyMapping fields. PKIX standard requires that, if present in a CA certificate, the extension must never consist of a null sequence. At least one of the two specified fields must be present.
For general information about this extension, see "policyConstraints" on page 738.
During installation, CS automatically creates an instance of the policy constraints extension policy, named PolicyConstraintsExt, that is disabled by default.
Table 12-35 PolicyConstraintsExt Configuration Parameters
Policy
- -1 specifies that the field should not be set in the extension (default).
- 0 specifies that no subordinate CA certificates are permitted in the path before an explicit policy is required.
- n must be an integer that is greater than zero. It specifies at the most n subordinate CA certificates are allowed in the path before an explicit policy is required.
Mapping
- -1 specifies that the field should not be set in the extension (default).
- 0 specifies that no subordinate CA certificates are permitted in the path before policy mapping is no longer permitted.
- n must be an integer that is greater than zero. It specifies at the most n subordinate CA certificates are allowed in the path before policy mapping is no longer permitted. For example, a value of one indicates that policy mapping may be processed in certificates issued by the subject of this certificate, but not in additional certificates in the path.
PolicyMappingsExt
The PolicyMappingsExt plug-in module enables you to add the Policy Mappings Extension defined to certificates. The extension lists one or more pairs of OIDs, each pair identifying two policy statements of two CAs. The pairing indicates that the corresponding policies of one CA are equivalent to policies of another CA. The extension may be useful in the context of cross-certification. If supported, the extension is to be included in CA certificates only. The policy allows you to map policy statements of one CA to that of another by pairing the OIDs assigned to their policy statements
Each pair is defined by two parameters, issuerDomainPolicy and subjectDomainPolicy. The pairing indicates that the issuing CA considers the issuerDomainPolicy equivalent to the subjectDomainPolicy of the subject CA. The issuing CA's users may accept an issuerDomainPolicy for certain applications. The policy mapping tells these users which policies associated with the subject CA are equivalent to the policy they accept.
For general information about this extension, see "policyMappings" on page 739.
During installation, CS automatically creates an instance of the policy mappings extension policy, named PolicyMappingsExt, that is enabled by default.
Table 12-36 PolicyMappingsExt Configuration Parameters
issuerDomainPolicy
subjectDomainPolicy
PrivateKeyUsagePeriodExt
The PrivateKeyUsagePeriodExt plug-in module enables you to add the Private Key Usage Period Extension to certificates. The extension allows the certificate issuer to specify a different validity period for the private key than the one specified for the corresponding certificate. The extension is intended for use with digital signature keys.
For general information about this extension, see "privateKeyUsagePeriod" on page 739.
Table 12-37 PrivateKeyUsagePeriodExt Configuration Parameters
RemoveBasicConstraintsExt
The RemoveBasicConstraintsExt plug-in module implements the remove basic constraints extension policy. This policy, if enabled, can detect the presence of Basic Constraints extension in a certificate request and remove it.
For general information about the Basic Constraints extension, see "basicConstraints" on page 732.
Table 12-38 RemoveBasicConstraintsExt Configuration Parameters
SubjectAltNameExt
The SubjectAltNameExt plug-in module enables you to add the Subject Alternative Name Extension to certificates. The extension enables you to bind additional identities-such as Internet electronic mail address, a DNS name, an IP address, and a uniform resource indicator (URI)-to the subject of the certificate.
For general information about this extension, see "subjectAltName" on page 740.
The standard suggests that if the certificate subject field contains an empty sequence, then the subject alternative name extension must contain the subject's alternative name and that the extension be marked critical.
If you're using any of the directory-based authentication methods, you can configure CS to retrieve values for any string and byte attributes from the directory and set them in the certificate request during authentication-you specify these attributes by entering them in the ldapStringAttributes and ldapByteAttributes fields defined in the automated enrollment modules.
Note that all data related to an end entity is gathered at the servlet level and set on the request before the request is passed to the policy subsystem.
In general, you can configure which attributes should or shouldn't be stored in the request; for example, you can exclude sensitive attributes such as passwords from getting stored in the request with the help of the parameter named dontSaveHttpParams defined in the CS configuration file. For details on using this parameter, see the description for HTTP_PARAMS in section "JavaScript Used By All Interfaces" of CS Customization Guide. You can also distinguish the attributes based on their origin-that is, whether they originated from the enrollment form or where added to the request during the authentication process. Authenticated attributes have AUTH_TOKEN as prefix (for example, AUTH_TOKEN.mail) and non-authenticated attributes such as the ones that come from the HTTP input have HTTP_PARAMS as prefix (for example, HTTP_PARAMS.csrRequestorEmail).
If enabled, the subject alternative extension policy checks the certificate request for configured attributes. If the request contains an attribute, the policy reads its value and sets it in the extension. This way, the extension that gets to added to certificates contains all the configured attributes.
During installation, CS automatically creates an instance of the subject alternative name extension policy, named SubjectAltNameExt, that is enabled by default.
Table 12-39 SubjectAltNameExt Configuration Parameters
requestAttr
generalNameChoice
- Select rfc822Name if the request-attribute value is an Internet mail address in the local-part@domain format (default). For example, jdoe@example.com.
- Select directoryName if the request-attribute value is an X.500 directory name, similar to the subject name in a certificate. For example,
CN=Jane Doe, OU=Sales Dept, O=Example Corporation, C=US.
- Select URL if the request-attribute value is a non-relative URI that includes both a scheme (for example, http) and a fully qualified domain name or IP address of the host. For example, http://hr.example.com.
- Select iPAddress if the request-attribute value is a valid IP address specified in dot-separated numeric component notation. For example, 128.21.39.40.
- Select OID if the request-attribute value is a unique, valid OID specified in the dot-separated numeric component notation. For example, 1.2.3.4.55.6.5.99.
- Select otherName if the request-attribute value is the absolute path to the file that contains the base-64 encoded string of the subject alternative name. For example, /usr/netscape/servers/ext/san/othername.txt.
Before you edit the default rule, you should read the additional details about the attributes that are set in the default policy rule.
The first two attributes, AUTH_TOKEN.mail and AUTH_TOKEN.mailalternateaddress, are standard LDAP attributes typically used for storing end users' email addresses in an LDAP directory. These attributes enable you to include a user's email address as an alternative name in the certificate. Remember that you need to specify the LDAP attribute for users' email addresses as a part of configuring the server to use a specific directory for authentication-which means for the default rule to set end users' email addresses in the subject alternative name extension, you must ensure the following:
- The server is configured for directory-based or directory- and PIN-based (using directory attributes for forming subject names) enrollment; that is, you have created and configured an authentication instance.
- The ldapStringAttributes parameter in the authentication instance is set to mail or mailalternateaddress, or to both.
The third attribute, HTTP_PARAMS.csrRequestorEmail, is the email component of the subject name in an enrollment request-it is an HTTP input value that gets added to the request when a user uses the manual enrollment form; for details.
If you enable the default policy rule, the server automatically checks the certificate request for attributes AUTH_TOKEN.mail, AUTH_TOKEN.mailalternateaddress, and HTTP_PARAMS.csrRequestorEmail. If the server finds any of the attributes, it sets the attribute value in the extension and then adds the extension to certificates specified by the predicate parameter. If none of the attributes are in a request, the server does not add the subject alternative name extension to the certificate.
SubjectDirectoryAttributesExt
The SubjectDirectoryAttributesExt plug-in module enables you to add the Subject Directory Attributes Extension to certificates. The extension is used to specify any desired directory attribute values for the subject of the certificate.
For general information about this extension, see "subjectDirectoryAttributes" on page 740.
The subject directory attributes extension policy in CS allows you to include up to three directory attributes in the extension. For each attribute that you want to include in the extension, you need to specify the attribute name and its value-the name must be the X.500 directory attribute name itself and the attribute value can be derived from the request or directly entered in the policy configuration as a string value.
The list of directory attributes supported by default are shown as permissible values for the attribute<n>.attributeName parameter explained in Table 12-40 on page 538. You can extend the list of attributes supported by the policy by defining new X.500 directory attributes. For details on defining new attributes, see "Extending Attribute Support" on page 758.
Note that, during installation, CS does not create an instance of the subject directory attributes extension policy. If you want the server to add this extension to certificates, you must create an instance of the SubjectDirectoryAttributesExt module and configure it.
Table 12-40 SubjectDirectoryAttributesExt Configuration Parameters
- Select Request Attribute if you want the server to read the value from the request attribute.
- Select Fixed Value if you want to specify a fixed value for the attribute.
Note that both the options require you to enter the value for the attribute in the attribute<n>.value field. The server will set the extension with this value in all certificates specified by the predicate parameter.
SubjectKeyIdentifierExt
The SubjectKeyIdentifierExt plug-in module enables you to add the Subject Key Identifier Extension to certificates. The extension is used to identify certificates that contain a particular public key-that is, the extension is used to uniquely identify a certificate from among several that have the same subject name.
For general information about this extension, see "authorityKeyIdentifier" on page 744.
You can also customize the method for deriving the Key Identifier using the CS SDK by subclassing the policy and overriding the following method:
formKeyIdentifier(X509CertInfo certInfo, IRequest req)
If enabled, the policy adds a Subject Key Identifier Extension to an enrollment request if the extension does not already exist. If the extension exists in the request, for example from a CRMF request, the policy replaces the extension. In case of agent-approved enrollments, after an agent approves the enrollment request, the policy accepts any Subject Key Identifier Extension that is already there.
During installation, CS automatically creates an instance of the subject key identifier extension policy, named SubjectKeyIdentifierExt that is enabled by default.
Table 12-41 SubjectKeyIdentifierExt Configuration Parameters
- SHA1 specifies that the key identifier must be derived as a 20 byte (160 bit) SHA-1 hash of the BIT STRING of Subject Public Key (default).
- TypeField specifies that the key identifier must be derived as a type field value of 0100 followed by 60 least significant bits of the SHA-1 hash of the Subject Public Key.
- SpkiSHA1 specifies that the key identifier must be derived as a 20 byte (160 bit) SHA-1 hash of the Subject Public Key Info.
Managing Policy Plug-in Modules
This section explains how to use the CS window to perform the following operations:
Registering a Policy Module
You can register new policy plug-in modules in a subsystem's policy framework. Registering a new policy module involves specifying the name of the module and the full name of the Java class that implements the policy interface. For example, you can add a policy implementation, named as follows, to the Data Recovery Manager's policy framework: com.redhat.policy.KeyArchivalPolicy
Before registering a plug-in module, be sure to put the Java class for the module in the classes directory (the implementation must be on the class path).
To register a policy module in a subsystem's policy framework:
- 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 that will use the module you want to register.
- Select Policies, and then in the right pane, select the Policy Plugin Registration tab.
- Class name. Type the full name of the class for this module-that is, the path to the implementing Java class. If this class is part of a package, be sure to include the package name. For example, if you are registering a class named customPolicy and if this class is in a package named com.customplugins, type com.customplugins.customPolicy.
Deleting a Policy Module
You can delete unwanted policy plug-in modules using the CS window. Before deleting a module, be sure to delete all the policy rules that are based on this module.
To delete a policy module from a subsystem's policy framework:
- 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 that registers the module you want to delete.
- Select Policies, and then in the right pane, select the Policy Plugin Registration tab.
| Previous |
Contents |
Index |
Next |