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

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.

Using policies, you can configure CS to perform one or more of the following operations on each certificate issuance or management request it receives:

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:

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:

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:

After all the policy rules are applied, the processor determines the status of the request (in this order):

  1. 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.
  2. 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.
  3. 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  
Operator
Description
==
Equal to
!=
Not equal to
AND
Logical operator AND
OR
Logical operator OR

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

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

is interpreted as

(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:

Table 12-2 lists default attributes that are supported by various request object implementations.

Table 12-2 Attributes supported by request object implementations  
Request type
Variable name
Description
Default attributes from an input form:
Enrollment
requestFormat
Specifies the certificate request format. Default values include the following:
  • keygen
  • pkcs10
  • clientAuth
Enrollment
certType
Specifies the certificate type. Default values include the following:
  • 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)
Enrollment
doSslAuth
Specifies whether the client is required to do SSL client authentication during enrollment. Default values include the following:
Enrollment
certauthEnroll
Specifies whether it is a certificate-based enrollment. Default values include the following:
Enrollment
certauthEnrollType
Specifies the number of keys to be generated for a certificate-authenticated enrollment-whether a single signing key, a single encryption key, or dual keys (one for signing and another for encryption) is to be generated. Default values include the following:
  • single
  • encryption
  • dual
Enrollment
cepsubstore
Specifies the name of the CEP service; for example, cep1 and cep2. When setting up multiple CEP services, you can use predicates to differentiate one service for another; see "CEP Enrollment" on page 395.
Enrollment, Renewal, and Revocation
requestStatus
Specifies when (or the phase in which) a request gets subjected to policy processing:
  • begin specifies that the request be subjected to a policy before it gets queued for agent approval.
  • pending specifies that the request be subjected to a policy after agent approval.
Renewal
requestFormat
Specifies the certificate request format. Default values include the following:
  • clientAuth
  • pkcs10
Default attributes from an authentication token:
(Upon successful authentication these attributes go into an enrollment request)
Enrollment
authMgrImplName
Specifies the name of the authentication plug-in module that authenticated the request.
Enrollment
authMgrInstName
Specifies the name of the authentication instance that authenticated the request.

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:

  1. Open the corresponding HTML file in a text editor.
  2. Locate the section that lists the HTTP input variables.
  3. Add this line: <input type="HIDDEN" name="orgunit" value="Sales">
  4. 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:

  1. Create a new instance of the ValidityConstraints policy plug-in implementation.
  2. 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!=Sales

The 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:

  1. Log in to the CS window (see "Logging Into the CS Console" on page 239).
  2. Select the Configuration tab.
  3. In the navigation tree, select the subsystem to which the policy rule you want to modify belongs.
  4. Select Policies.
The Policy Rules Management tab appears. It lists configured policy rules.
  1. In the Policy Rule list, select a rule that you want to modify.
For the purposes of this instruction, assume that you selected the rule named DefaultValidityRule.
  1. Click Edit/View.
The Policy Rule Editor window appears, showing how this rule is configured.
  1. Make the necessary changes and click OK.
You are returned to the Policy Rules Management tab.
  1. Repeat steps 5 through 7 for the remaining rules.
  2. Click Refresh.

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:

  1. In the Policy Rules Management tab, select the rule you want to delete and click Delete.
  2. 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:

To add a new policy rule to the CS configuration:

  1. In the Policy Rules Management tab, click Add.
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.
  1. Select a plug-in module.
  2. Click Next.
The Policy Rule Editor window appears, listing the configuration information.
  1. Enter the appropriate information.
  2. Click OK.
You are returned to the Policy Rules Management tab.
  1. Repeat steps 1 through 5 and create additional rules, if required.

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:

  1. In the Policy Rules Management tab, click Reorder.
The Reorder Policy Rules window appears. It lists configured policy rules in the order in which they are executed by the subsystem.
  1. 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.
  1. When you have the correct order, click OK.
You are returned to the Policy Rules Management tab.
  1. To view the updated configuration, click Refresh.

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.

  1. Enroll for a Certificate
  2. Approve the Request
  3. Check the Certificate Details

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:

CS uses the Rhino JavaScript engine from Mozilla.org. You can get more details about the Rhino project from this site:

http://www.mozilla.org/rhino

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.

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  
Parameter
Description
enable
Specifies whether the rule is enabled or disabled. Select to enable (default), deselect to disable.
predicate
Specifies the predicate expression for this rule. If you want this rule to be applied to all certificate requests, leave the field blank (default). To form a predicate expression, see "Using Predicates in Policy Rules" on page 465.
ldap.ldapconn.host
Specifies the host name of the LDAP directory to connect to.
Permissible values: The name must be fully-qualified host name in the <machine_name>.<your_domain>.<domain> form.
Example: corpDirectory.example.com
ldap.ldapconn.port
Specifies the TCP/IP port at which the LDAP directory listens to requests from CS.
Permissible values: Any valid port number. The default is 389; use 636 if the directory is configured for SSL-enabled communication.
ldap.ldapconn.secureConn
Specifies the type-SSL or non-SSL-of the port at which the LDAP directory listens to requests from CS. Select for SSL, deselect for non-SSL.
ldap.ldapconn.version
Specifies the LDAP protocol version:
  • 2 specifies LDAP version 2. If your directory is based on Red Hat Directory Server 1.x, choose 2.
  • 3 specifies LDAP version 3. For Directory Server versions 3.x and later, choose 3 (default).
ldap.ldapauth.bindDN
Specifies the user entry to bind as for checking the attribute in the LDAP directory.
Example: CN=pinmanager
password
Specifies the password associated with the DN specified by the ldap.ldapauth.bindDN parameter.
ldap.ldapauth.clientCertNickname
Specifies the nickname or the friendly name of the certificate to be used for SSL client authentication to the LDAP directory in order to check attributes. Make sure that the certificate is valid and has been signed by a CA that is trusted in the directory's certificate database, and that the directory's certmap.conf file has been configured to correctly map the certificate to a DN in the directory. (This is needed for PIN removal only.)
Example: Server-Cert
ldap.ldapauth.authtype
Specifies how to bind to the directory or the authentication type-basic authentication or SSL client authentication-required in order to check attributes in the LDAP directory:
  • 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.
ldap.ldapconn.basedn
Specifies the base DN for searching the LDAP directory-the plug-in uses the value of the uid field from the HTTP input (what a user enters in the enrollment from) and the base DN to construct an LDAP search filter.
Permissible values: Any valid DN string of up to 255 characters. (If your user's DN is uid=jdoe, o=company, you might want to use o=company here.)
Example: O=example.com
ldap.ldapconn.minConns
Specifies the minimum number of connections permitted (or to keep open) to the LDAP directory. Permissible values: 1 to 3; the default value is 1.
ldap.ldapconn.maxConns
Specifies the maximum number of connections permitted to the LDAP directory; when needed, connection pool can grow to this many (multiplexed) connections. Permissible values: 3 to 10; the default value is 5.
attribute
Specifies the LDAP attribute, the presence of which is to be checked in the certificate-enrollment request. Permissible values: Valid directory attributes, separated by commas; the default value is pin.
value
If this parameter is non-empty, the attribute value must match this value for the request to proceed to the next stage.

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  
Parameter
Description
enable
Specifies whether the rule is enabled or disabled. Select to enable (default), deselect to disable.
predicate
Specifies the predicate expression for this rule. If you want this rule to be applied to all certificate requests, leave the field blank (default). To form a predicate expression, see "Using Predicates in Policy Rules" on page 465.
minSize
Specifies the minimum length, in bits, for the key (the length of the modulus in bits). The value must be smaller than or equal to the one specified by the maxSize parameter. Permissible values: 512 or 1024. You may also enter a custom key size that is between 512 and 1024, in increments of 64 bits. The default value is 512.
maxSize
Specifies the maximum length, in bits, for the key. Permissible values: 512 or 1024. You may also enter a custom key size that is between 512 and 1024, in increments of 64 bits. The default value is 1024.
exponents
Limits the possible public exponent values. Use commas to separate different values.
Some exponents are more widely used than others. The following exponent values are recommended for arithmetic and security reasons: 17 and 65537. Of these two values, 65537 is preferred. (This setting is mainly an issue if you are using your own software for generating key pairs. Key-generation programs in Red Hat clients and servers use 3 or 65537.)
Permissible values: A combination of 3, 7, 17, and 65537, separated by commas. The default value is 3,7,17,65537.

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  
Parameter
Description
enable
Specifies whether the rule is enabled or disabled. Select to enable (default), deselect to disable.
predicate
Specifies the predicate expression for this rule. If you want this rule to be applied to all certificate requests, leave the field blank (default). To form a predicate expression, see "Using Predicates in Policy Rules" on page 465.
issuerDN
Specifies the name of the CA that has issued certificates that are to be checked. You should enter the issuer name as it appears in the CA's signing certificate; the same name also appears as the issuer name in certificates the CA signs.
Example: CN=bulkGenCA,OU=Information Systems,O=Example Corporation,C=US

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  
Parameter
Description
enable
Specifies whether the rule is enabled or disabled. Select to enable (default), deselect to disable.
predicate
Specifies the predicate expression for this rule. If you want this rule to be applied to all certificate requests, leave the field blank (default). To form a predicate expression, see "Using Predicates in Policy Rules" on page 465.
algorithms
Specifies the key type the server should certify. The default is RSA.
Permissible values: RSA or RSA.

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  
Parameter
Description
enable
Specifies whether the rule is enabled or disabled. Select to enable the rule (default). Deselect to disable the rule.
predicate
Specifies the predicate expression for this rule. If you want this rule to be applied to all certificate requests, leave the field blank (default). To form a predicate expression, see "Using Predicates in Policy Rules" on page 465.
allowExpiredCerts
Specifies whether to allow or prevent renewal of expired certificates. Select if you want the server to renew expired certificates (default). Deselect if you don't want the server to renew expired certificates.
renewalNotAfter
Specifies how long, in days, after the expiration of a certificate can it be renewed. The default value is 30 days. If you leave the field blank, the server will renew all expired certificates that are submitted for renewal.

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  
Parameter
Description
enable
Specifies whether the rule is enabled or disabled. Select to enable (default), deselect to disable.
predicate
Specifies the predicate expression for this rule. If you want this rule to be applied to all certificate requests, leave the field blank (default). To form a predicate expression, see "Using Predicates in Policy Rules" on page 465.
minValidity
Specifies the minimum validity period, in days, for renewed certificates.
maxValidity
Specifies the maximum validity period, in days, for renewed certificates.
renewalInterval
Specifies how many days before its expiration that a certificate can be renewed.

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  
Parameter
Description
enable
Specifies whether the rule is enabled or disabled. Select to enable (default), deselect to disable.
predicate
Specifies the predicate expression for this rule. If you want this rule to be applied to all certificate requests, leave the field blank (default). To form a predicate expression, see "Using Predicates in Policy Rules" on page 465.
allowExpiredCerts
Specifies whether to allow or prevent revocation of expired certificates. Select if you want the server to revoke expired certificates (default). Deselect if you don't want the server to revoke expired certificates.

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  
Parameter
Description
enable
Specifies whether the rule is enabled or disabled. Select to enable the rule (default). Deselect to disable the rule.
predicate
Specifies the predicate expression for this rule. If you want this rule to be applied to all certificate requests, leave the field blank (default). To form a predicate expression, see "Using Predicates in Policy Rules" on page 465.
minSize
Specifies the minimum length, in bits, for the key (the length of the modulus in bits). The value must be smaller than or equal to the one specified by the maxSize parameter. Permissible values: 512, 1024, 2048, or 4096. You may also enter a custom key size that is between 512 and 4096 bits. The default value is 512.
maxSize
Specifies the maximum length, in bits, for the key. Permissible values: 512, 1024, 2048, or 4096. You may also enter a custom key size that is between 512 and 4096 bits. The default value is 2048.
exponents
Limits the possible public exponent values. Use commas to separate different values.
Some exponents are more widely used than others. The following exponent values are recommended for arithmetic and security reasons: 17 and 65537. Of these two values, 65537 is preferred. (This setting is mainly an issue if you are using your own software for generating key pairs. Key-generation programs in Red Hat clients and servers use 3 or 65537.)
Permissible values: A combination of 3, 7, 17, and 65537, separated by commas. The default value is 3,7,17,65537.

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

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  
Parameter
Description
enable
Specifies whether the rule is enabled or disabled. Select to enable (default), deselect to disable.
predicate
Specifies the predicate expression for this rule. If you want this rule to be applied to all certificate requests, leave the field blank (default). To form a predicate expression, see "Using Predicates in Policy Rules" on page 465.
algorithms
Specifies the signature algorithm the server should use to sign certificates.
Permissible values: Depends on the CA's signing key type (the key type you chose for the Certificate Manager's CA signing certificate).
  • If the key type is RSA, select one of the following:
    - MD2withRSA,MD5withRSA,SHA1withRSA
    - MD2withRSA,MD5withRSA
    - MD2withRSA,SHA1withRSA
    - MD5withRSA,SHA1withRSA
    - MD2withRSA
    - MD5withRSA
    - SHA1withRSA
    The default value is MD2withRSA,MD5withRSA,SHA1withRSA.
  • If the key type is DSA, select SHA1withDSA.

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  
Parameter
Description
enable
Specifies whether the rule is enabled or disabled. Select to enable, deselect to disable (default).
predicate
Specifies the predicate expression for this rule. If you want this rule to be applied to all certificate requests, leave the field blank (default). To form a predicate expression, see "Using Predicates in Policy Rules" on page 465.

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