Previous     Contents     Index     Next     
iPlanet Certificate Management System Plug-ins Guide



Chapter 3   Constraints Policy Plug-in Modules


You can configure iPlanet Certificate Management System (CMS) to apply certain organizational policies to an end entity's certificate enrollment, renewal, and revocation requests before servicing them. For example, some of the policies you might want Certificate Management System to apply to 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.

Certificate Management System comes with various policy plug-in modules that define the formulation of a certificate's content and govern the server's certificate generation and management operations. The modules are categorized, based on their functionality, into two groups: constraints-specific policy modules and extension-specific policy modules.

This chapter explains the constraints-specific policy plug-in modules in detail—it lists and briefly describes the modules that are installed with Certificate Management System, and then explains each one in detail. For details on extension-specific modules, see Chapter 4 "Certificate Extension Plug-in Modules".

The chapter has the following sections:



Overview of Constraints-Specific Policy Modules

Constraints-specific policy plug-in modules help you define rules or constraints that Certificate Management System 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.

Policy plug-in modules are implemented as Java classes and are registered in the CMS policy framework. The Policy Plugin Registration tab of the CMS window (Figure 3-1) lists all the modules that are registered with a CMS instance.

Figure 3-1    CMS window showing policy modules registered with a Certificate Manager


Table 3-1 lists constraints-specific policy modules that are installed with a Certificate Manager. An installation of a Registration Manager also includes all these modules, expect for the ones noted below:

  • IssuerConstraints

  • SubCANameConstraints

  • UniqueSubjectNameConstraints

Note that the name of the Java class for a policy plug-in module is in this format:

com.netscape.certsrv.policy.<plugin_name>

where <plugin_name> is the name of a plug-in module. For example, the Java class for the AttributePresentConstraints module would be:

com.netscape.certsrv.policy.AttributePresentConstraints

You can use whichever modules you need in order to define policy rules for a Certificate Manager or Registration Manager. Note that no modules are provided for the Data Recovery Manager. Both Certificate Manager and Registration Manager subject a request to policy checking as explained in section "Policy Processor" in Chapter 18, "Setting Up Policies" of CMS Installation and Setup Guide.

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.


Table 3-1    Default constraints-specific policy plug-in modules  

Plug-in module name

Function

AttributePresentConstraints  

Rejects a request if an LDAP attribute is not present in the enrolling user's directory entry or if the attribute does not have a specified value. For details, see "AttributePresentConstraints Plug-in Module".  

DSAKeyConstraints  

Certifies only those DSA keys that have specific key lengths. For details, see "DSAKeyConstraints Plug-in Module".  

IssuerConstraints  

Checks for certificates that have been issued by a particular CA. For details, see "IssuerConstraints Plug-in Module".  

KeyAlgorithmConstraints  

Certifies only those keys that are generated using one of the permitted algorithms, such as RSA or DSA. For details, see "KeyAlgorithmConstraints Plug-in Module".  

RenewalConstraints  

Allows or rejects requests for renewal of expired certificates. For details, see "RenewalConstraints Plug-in Module".  

RenewalValidityConstraints  

Enforces the number of days before which a currently active certificate can be renewed and sets a new validity period for the renewed certificate. For details, see "RenewalValidityConstraints Plug-in Module".  

RevocationConstraints  

Allows or rejects requests for revocation of expired certificates. For details, see "RevocationConstraints Plug-in Module".  

RSAKeyConstraints  

Certifies only those RSA keys that have specific key lengths. For details, see "RSAKeyConstraints Plug-in Module".  

SigningAlgorithmConstraints  

Specifies the signature algorithm to be used by the CA (a Certificate Manager) to sign certificates. For details, see "SigningAlgorithmConstraints Plug-in Module".  

SubCANameConstraints  

Checks for issuer name uniqueness and prevents a CA from issuing a subordinate CA certificate with issuer name same as its own. For details, see "SubCANameConstraints Plug-in Module".  

UniqueSubjectNameConstraints  

Checks for certificate subject name uniqueness and prevents issuance of multiple certificates with same subject names. For details, see "UniqueSubjectNameConstraints Plug-in Module".  

ValidityConstraints  

Checks whether the validity period of a certificate falls within a specific validity period. For details, see "ValidityConstraints Plug-in Module".  



AttributePresentConstraints Plug-in Module


The AttributePresentConstraints plug-in module implements the attribute present constraints policy. The 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. An example usage is in "Step 3. Enable the AttributePresentConstraints Policy" in Chapter 15, "Setting Up End-User Authentication" of CMS Installation and Setup Guide.

Note that many of the parameters defined in the module (see Table 3-2) are specified in the same way as the modules provided for authenticating users during directory-based enrollment.

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 attribute named in the attribute parameter is present in the request, the policy accepts the request.

    • If the attribute named in the attribute parameter is not present in the request, the policy rejects the request.

  • If the value parameter is not empty, the policy checks its value with the value of the attribute specified in the attribute parameter.

    • If the attribute named in the attribute parameter has the specified value, the policy accepts the request.

    • If the attribute named in the attribute parameter does not have the specified value, the policy rejects the request.

    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, Certificate Management System does not create an instance of the attribute present constraints policy during installation. If you want to create an instance of the AttributePresentConstraints module, see section "Step 4. Add New Policy Rules" in Chapter 18, "Setting Up Policies" of CMS Installation and Setup Guide.


Configuration Parameters of AttributePresentConstraints

In the CMS configuration file, the AttributePresentConstraints module is identified as <subsystem>.Policy.impl.AttributePresentConstraints.
class=com.netscape.certsrv.policy.AttributePresentConstraints, where <subsystem> is ca or ra (prefix identifying the subsystem).

In the CMS window, the module is identified as AttributePresentConstraints. Figure 3-2 shows how configurable parameters for the module are displayed in the CMS window.

Figure 3-2    Parameters of the AttributePresentConstraints module


The configuration shown in Figure 3-2 creates a policy rule named PinCheckForClientCerts, which enforces a rule that the server should check for users PINs in the specified LDAP directory.

Table 3-2 describes each of the parameters.


Table 3-2    Description of parameters defined in the AttributePresentConstraints module  

Parameter

Description

enable  

Specifies whether the rule is enabled or disabled. Check the box to enable the rule (default). Uncheck the box to disable the rule.

  • If you enable the rule and set the remaining parameters correctly, the server applies the rule to certificates specified by the predicate expression.

  • If you disable the rule, the server does not apply the rule to certificates.

 

predicate  

Specifies the predicate expression for this rule. If you want the rule to be applied to all certificate requests, leave the field blank (default). To form a predicate expression, see section "Using Predicates in Policy Rules" in Chapter 18, "Setting Up Policies" of CMS Installation and Setup Guide.

Example: HTTP_PARAMS.certType==client  

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.siroe.com  

ldap.ldapconn.port  

Specifies the TCP/IP port at which the LDAP directory listens to requests from Certificate Management System.

Permissible values: Any valid port number. The default is 389; use 636 if the directory is configured for SSL-enabled communication.

Example: 389  

ldap.ldapconn.secureConn  

Specifies the type—SSL or non-SSL—of the port at which the LDAP directory listens to requests from Certificate Management System.

  • Check the box if the port is an SSL (HTTPS) port. If your directory is configured for SSL-enabled communication (with or without SSL client authentication), choose this option.

  • Leave the box unchecked if the port is a non-SSL (HTTP) port. If your directory is configured for basic authentication, choose this option (default).

 

ldap.ldapconn.version  

Specifies the LDAP protocol version.

Permissible values: 2 or 3.

  • 2 specifies LDAP version 2. If your directory is based on Netscape Directory Server 1.x, choose 2.

  • 3 specifies LDAP version 3. For Directory Server versions 3.x and later, choose 3 (default).

Example: 3  

ldap.ldapauth.bindDN  

Specifies the user entry to bind as for checking the attribute in the LDAP directory.

Permissible values: A valid bind DN.

Example: CN=pinmanager  

password  

Specifies the password associated with the DN specified by the ldap.ldapauthbindDN 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.)

Permissible values: Enter the name of a currently valid CMS certificate, for example, its SSL server certificate.

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.

Permissible values: BasicAuth or SslClientAuth.

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

Example: BasicAuth  

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=siroe.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.

Example: 3  

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.

Example: 9  

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.

Example: 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 Plug-in Module


The DSAKeyConstraints plug-in module implements the DSA key constraints policy. This policy imposes constraints on the following:

  • The minimum and maximum sizes for keys

  • The sizes of exponents

The policy restricts the key size to one of the sizes, such as 512 or 1024, supported by Certificate Management System.

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 Certificate Management System to do so using the policy.

During installation, Certificate Management System automatically creates an instance of the DSA key constraints policy. See "DSAKeyRule Rule".


Configuration Parameters of DSAKeyConstraints

In the CMS configuration file, the DSAKeyConstraints module is identified as <subsystem>.Policy.impl.DSAKeyConstraints.class=
com.netscape.certsrv.policy.DSAKeyConstraints, where <subsystem> is ca or ra (prefix identifying the subsystem).

In the CMS window, the module is identified as DSAKeyConstraints. Figure 3-3 shows how configurable parameters for the module are displayed in the CMS window.

Figure 3-3    Parameters of the DSAKeyConstraints module


The configuration shown in Figure 3-3 creates a policy rule named DSAKeySizeForClientCert, which enforces a rule that the server should restrict the minimum and maximum key sizes for all DSA key-based client certificates to 512 and 1024, respectively.

Table 3-3 describes each of the parameters.


Table 3-3    Description of parameters defined in the DSAKeyConstraints module  

Parameter

Description

enable  

Specifies whether the rule is enabled or disabled. Check the box to enable the rule (default). Uncheck the box to disable the rule.

  • If you enable the rule and set the remaining parameters correctly, the server applies the rule to certificates specified by the predicate expression.

  • If you disable the rule, the server does not apply the rule to certificates.

 

predicate  

Specifies the predicate expression for this rule. If you want the rule to be applied to all certificate requests, leave the field blank (default). To form a predicate expression, see section "Using Predicates in Policy Rules" in Chapter 18, "Setting Up Policies" of CMS Installation and Setup Guide.

Example: HTTP_PARAMS.certType==client  

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.

In general, a longer key size results in a key pair that is more difficult to crack. You may want to enforce a minimum length to ensure a minimum level of security.

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.

Example: 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.

Example: 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 Netscape 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.

Example: 17,65537  


DSAKeyRule Rule

The rule named DSAKeyRule is an instance of the DSAKeyConstraints module. Certificate Management System automatically creates this rule during installation. By default, the rule is configured as follows:

  • The rule is enabled.

  • The predicate expression is left blank so that the rule is applied to all certificate enrollment and renewal requests processed by the server.

  • The minimum key size permitted for certificates is 512 bits (minSize=512).

  • The maximum key size permitted for certificates is 1024 bits (maxSize=1024).

  • The exponents allowed are 3, 7, 17, and 65537 (exponents=3,7,17,65537).

For details on individual parameters defined in the rule, see Table 3-3. You need to review this rule and make the changes appropriate for your PKI setup. For instructions, see section "Step 2. Modify Existing Policy Rules" in Chapter 18, "Setting Up Policies" of CMS Installation and Setup Guide. For instructions on adding additional instances, see section "Step 4. Add New Policy Rules" in the same chapter.



IssuerConstraints Plug-in Module


The IssuerConstraints plug-in module implements the issuer constraints policy. The policy enables you to effectively deploy certificate-based enrollment explained in "Certificate-Based Enrollment".

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, Certificate Management System automatically creates an instance of the issuer constraints policy. See "IssuerRule Rule". The server also provides appropriate enrollment forms for the three certificate-based enrollment scenarios explained above; see "Enrollment Forms".


Configuration Parameters of IssuerConstraints

In the CMS configuration file, the IssuerConstraints module is identified as ca.Policy.impl.IssuerConstraints.class=com.netscape.certsrv.
policy.IssuerConstraints.

In the CMS window, the module is identified as IssuerConstraints. Figure 3-4 shows how the configurable parameters for the module are displayed in the CMS window.

Figure 3-4    Parameters of the IssuerConstraints module


The configuration shown in Figure 3-4 creates a policy rule named IssuerNameCheckInCert, which enforces a rule that the server should check for certificates issued by a CA, whose issuer DN is CN=bulkGenCA,OU=Information Systems,O=Siroe Corp,C=US.

Table 3-4 describes each parameter.


Table 3-4    Description of parameters defined in the IssuerConstraints module  

Parameter

Description

enable  

Specifies whether the rule is enabled or disabled. Check the box to enable the rule (default). Uncheck the box to disable the rule.

  • If you enable the rule and set the remaining parameters correctly, the server checks for certificates issued by the specified CA and enforces certificate-based enrollment.

  • If you disable the rule, the server does not check for certificates issued by a CA; it ignores the values specified in the remaining fields.

 

predicate  

Specifies the predicate expression for this rule. If you want the rule to be applied to all certificate requests, leave the field blank (default). To form a predicate expression, see section "Using Predicates in Policy Rules" in Chapter 18, "Setting Up Policies" of CMS Installation and Setup Guide.

Example: HTTP_PARAMS.certType==client AND certauthEnroll==on  

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.

Permissible values: A valid issuer name.

Example: CN=bulkGenCA,OU=Information Systems,O=Siroe Corp,C=US  


IssuerRule Rule

The rule named IssuerRule is an instance of the IssuerConstraints module. Certificate Management System automatically creates this rule during installation. By default, the rule is configured as follows:

  • The rule is disabled; for the rule to be effective, it must be enabled and configured appropriately.

  • The predicate expression is set (predicate=HTTP_PARAMS.certType==client AND certauthEnroll==on) so that the rule is applied to only those client-certificate requests that have certificate-based authentication turned on.

  • The issuer DN field is left blank for you to enter the appropriate information.

For details on individual parameters defined in the rule, see Table 3-4. You need to review this rule and make the changes appropriate for your PKI setup. For instructions, see section "Step 2. Modify Existing Policy Rules" in Chapter 18, "Setting Up Policies" of CMS Installation and Setup Guide. For instructions on adding additional instances, see section "Step 4. Add New Policy Rules" in the same chapter.



KeyAlgorithmConstraints Plug-in Module


The KeyAlgorithmConstraints plug-in module implements the key algorithm constraints policy. This policy restricts the key algorithm requested in certificates to the algorithms, such as RSA and DSA, supported by Certificate Management System. In other words, this policy allows you to set restrictions on the types of public keys certified by Certificate Management System.

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, Certificate Management System automatically creates an instance of the key algorithm constraints policy. See "KeyAlgRule Rule".


Configuration Parameters of KeyAlgorithmConstraints

In the CMS configuration file, the KeyAlgorithmConstraints module is identified as <subsystem>.Policy.impl.KeyAlgorithmConstraints.class=
com. netscape.certsrv.policy.KeyAlgorithmConstraints, where <subsystem> is ca or ra (prefix identifying the subsystem).

In the CMS window, the module is identified as KeyAlgorithmConstraints. Figure 3-5 shows how the configurable parameters for the module are displayed in the CMS window.

Figure 3-5    Parameters of the KeyAlgorithmConstraints module


The configuration shown in Figure 3-5 creates a policy rule named KeyAlgForClientServerCert, which enforces a rule that the server should restrict the key algorithm of all client and server certificates to RSA.

Table 3-5 gives details about each of the parameters.


Table 3-5    Description of parameters defined in the KeyAlgorithmConstraints module  

Parameter

Description

enable  

Specifies whether the rule is enabled or disabled. Check the box to enable the rule (default). Uncheck the box to disable the rule.

  • If you enable the rule and set the remaining parameters correctly, the server sets the configured algorithm in certificates specified by the predicate parameter.

  • If you disable the rule, the server sets the algorithm specified in the certificate request.

 

predicate  

Specifies the predicate expression for this rule. If you want the rule to be applied to all certificate requests, leave the field blank (default). To form a predicate expression, see section "Using Predicates in Policy Rules" in Chapter 18, "Setting Up Policies" of CMS Installation and Setup Guide.

Example: HTTP_PARAMS.certType==client AND
HTTP_PARAMS.certType==server  

algorithms  

Specifies the key type the server should certify. The default is RSA.

Permissible values: RSA, DSA, or RSA,DSA.

Example: RSA  


KeyAlgRule Rule

The rule named KeyAlgRule is an instance of the KeyAlgorithmConstraints module. Certificate Management System automatically creates this rule during installation. By default, the rule is configured as follows:

  • The rule is enabled.

  • The predicate expression is left blank so that the rule is applied to all certificate enrollment and renewal requests processed by the server.

  • The key type allowed is RSA (algorithms=RSA).

For details on individual parameters defined in the rule, see Table 3-5. You need to review this rule and make the changes appropriate for your PKI setup. For instructions, see section "Step 2. Modify Existing Policy Rules" in Chapter 18, "Setting Up Policies" of CMS Installation and Setup Guide. For instructions on adding additional instances, see section "Step 4. Add New Policy Rules" in the same chapter.



RenewalConstraints Plug-in Module


The RenewalConstraints plug-in module implements the renewal constraints policy. This policy 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. For example, if you don't want to allow renewal of expired certificates, you can configure the server accordingly using the policy.

In certain situations you may want to allow renewal of expired certificates. Here's one such scenario: the renewal validity constraints policy (see "RenewalValidityConstraints Plug-in Module") allows you to delay renewal of certificates as long as possible to reduce the overhead of processing new certificate requests. Typically, you would limit the renewal process to the last few weeks of validity of the certificate. However, if the interval specified in the policy rule is not sufficient for renewal to occur, some of your users may not be able to renew their certificates prior to the expiration time and end up owning expired certificates.

Note that the policy also allows you to specify how long after the expiration of a certificate can it be renewed. If you don't specify this, the server will renew all expired certificates that are submitted for renewal.

During installation, Certificate Management System automatically creates an instance of the renewal constraints policy. See "RenewalConstraintsRule Rule".


Configuration Parameters of RenewalConstraints

In the CMS configuration file, the RenewalConstraints module is identified as <subsystem>.Policy.impl.RenewalConstraints.class=
com.netscape.certsrv.policy.RenewalConstraints, where <subsystem> is ca or ra (prefix identifying the subsystem).

In the CMS window, the module is identified as RenewalConstraints. Figure 3-6 shows how the configurable parameters for the module are displayed in the CMS window.

Figure 3-6    Parameters of the RenewalConstraints module


The configuration shown in Figure 3-6 creates a policy rule named RenewExpiredClientCert, which specifies that the server should allow renewal of expired client certificates, if it's done within 30 days from the expiry date.

Table 3-6 gives details about each of the parameters.


Table 3-6    Description of parameters defined in the RenewalConstraints module  

Parameter

Description

enable  

Specifies whether the rule is enabled or disabled. Check the box to enable the rule (default). Uncheck the box to disable the rule.

  • If you enable the rule and set the remaining parameters correctly, the server verifies the validity period of the certificate being renewed, checks the value assigned to the allowExpiredCerts parameter, and accordingly allows or denies the renewal request.

  • If you disable the rule, the server does not verify the validity period of the certificate being renewed; it simply renews the certificate.

 

predicate  

Specifies the predicate expression for this rule. If you want the rule to be applied to all certificate requests, leave the field blank (default). To form a predicate expression, see section "Using Predicates in Policy Rules" in Chapter 18, "Setting Up Policies" of CMS Installation and Setup Guide.

Example: HTTP_PARAMS.certType==client  

allowExpiredCerts  

Specifies whether to allow or prevent renewal of expired certificates. Check the box if you want the server to renew expired certificates (default). Uncheck the box 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.

Example: 15  


RenewalConstraintsRule Rule

The rule named RenewalConstraintsRule is an instance of the RenewalConstraints module. Certificate Management System automatically creates this rule during installation. By default, the rule is configured as follows:

  • The rule is enabled.

  • The predicate expression is left blank so that the policy is applied to all certificate renewal requests processed by the server.

  • The server allows renewal of expired certificates within 30 days, starting from the date they expire.

For details on individual parameters defined in the rule, see Table 3-6. You need to review this rule and make the changes appropriate for your PKI setup. For instructions, see section "Step 2. Modify Existing Policy Rules" in Chapter 18, "Setting Up Policies" of CMS Installation and Setup Guide. For instructions on adding additional instances, see section "Step 4. Add New Policy Rules" in the same chapter.



RenewalValidityConstraints Plug-in Module


The RenewalValidityConstraints plug-in module implements the renewal validity constraints policy. This policy governs the formulation of content in the renewed certificate based on the currently issued certificate.

Every certificate issued by Certificate Management System is valid for a limited duration, which is determined by the validity period specified in the validity constraints policy (see "ValidityConstraints Plug-in Module") at the time the certificate is issued. In order to continue to participate in the PKI-using system beyond this validity period, the entity owning the certificate must renew the certificate; the new certificate generally contains a new validity time period and some updated attributes.

To eliminate administrative overhead of monitoring certificate validity periods and reminding users to renew their certificates, Certificate Management System provides a schedulable job that can detect any to-be-expired certificates and automatically remind users to renew their certificates. For details about this job, see "RenewalNotificationJob Plug-in Module".

The renewal validity constraints policy enables you to enforce certain restrictions on certificate-renewal requests, when end entities attempt to renew their certificates. You can specify restrictions on the following:

  • The number of days before expiration that end entities can renew their currently active or valid certificates. For example, if you want to prevent end entities from renewing their certificates any earlier than 15 days before expiration, you can configure the server accordingly using the policy.

  • The validity period of the renewed certificate. For example, if you want the validity period of all renewed certificates to be a minimum of 180 days, you can configure the server accordingly using the policy. Note that the renewal period starts from the ending period in the certificate presented for renewal.

Note that you may apply this policy to certificate renewal requests only, and the renewal process to which this policy is applied can be manual (a request needs to be approved by an agent) or automated. In both cases, the currently issued certificate must be either presented during SSL client authentication by the end entity or selected by the agent approving the renewal request.

By default, any validity requested in a certificate-renewal request cannot exceed beyond that of the expiration time specified in the CA's signing certificate (see section "CA Signing Key Pair Certificate" in Chapter 14, "Managing CMS Keys and Certificates" of CMS Installation and Setup Guide). If the Certificate Manager (CA) finds a request with validity period extending beyond that of its CA signing certificate, it automatically truncates the validity period to end on the day the CA signing certificate expires. For example, if the CA signing certificate expires on June 10, 2004, any renewal request with validity period beyond June 10, 2004 will have validity period truncated to end on June 10, 2004.

However, you can configure the Certificate Manager to renew certificates with validity periods beyond that of its CA signing certificate by selecting the "Override validity nesting requirement" option; see section "Step 6. Enable End-Entity Interaction" in Chapter 15, "Setting Up End-User Authentication" of CMS Installation and Setup Guide.

During installation, Certificate Management System automatically creates an instance of the renewal validity constraints policy. See "DefaultRenewalValidityRule Rule".


Configuration Parameters of RenewalValidityConstraints

In the CMS configuration file, the RenewalValidityConstraints module is identified as <subsystem>.Policy.impl.RenewalValidityConstraints.class=
com.netscape.certsrv.policy.RenewalValidityConstraints, where <subsystem> is ca or ra (prefix identifying the subsystem).

In the CMS window, the module is identified as RenewalValidityConstraints. Figure 3-7 shows how the configurable parameters for the module are displayed in the CMS window.

Figure 3-7    Parameters of the RenewalValidityConstraints module


The configuration shown in Figure 3-7 creates a policy rule named RenewalRuleForClientCert, which enforces a rule that the server should renew only those client certificates that are due to expire within the next 15 days. The renewed certificates are valid for at least 60 days (two months) and require renewing after 180 days (six months).

Table 3-7 gives details about each of the parameters.


Table 3-7    Description of parameters defined in the RenewalValidityConstraints module  

Parameter

Description

enable  

Specifies whether the rule is enabled or disabled. Check the box to enable the rule (default). Uncheck the box to disable the rule.

  • If you enable the rule and set the remaining parameters correctly, the server sets the configured validity period in renewed certificates specified by the predicate parameter.

  • If you disable the rule, the server sets the validity period as specified in the renewal request.

 

predicate  

Specifies the predicate expression for this rule. If you want the rule to be applied to all certificate requests, leave the field blank (default). To form a predicate expression, see section "Using Predicates in Policy Rules" in Chapter 18, "Setting Up Policies" of CMS Installation and Setup Guide.

Example: HTTP_PARAMS.certType==client  

minValidity  

Specifies the minimum validity period, in days, for renewed certificates.

Permissible values: As applicable. The default value is 180 days.

Example: 60  

maxValidity  

Specifies the maximum validity period, in days, for renewed certificates.

Permissible values: As applicable. The default value is 730 days.

Example: 180  

renewalInterval  

Specifies how many days before its expiration that a certificate can be renewed.

Permissible values: As applicable. The default value is 15 days.

Example: 15  


DefaultRenewalValidityRule Rule

The rule named DefaultRenewalValidityRule is an instance of the RenewalValidityConstraints module. Certificate Management System automatically creates this rule during installation. By default, the rule is configured as follows:

  • The rule is enabled.

  • The predicate expression is left blank so that the policy is applied to all certificate renewal requests processed by the server.

  • The minimum validity period permitted for renewed certificates is 30 days (minValidity=30).

  • The maximum validity period permitted for renewed certificates is 365 days (maxValidity=365).

  • The number of days before expiration that end entities can renew their currently valid certificates is 15 (renewalInterval=15).

For details on individual parameters defined in the rule, see Table 3-7. You need to review this rule and make the changes appropriate for your PKI setup. For instructions, see section "Step 2. Modify Existing Policy Rules" in Chapter 18, "Setting Up Policies" of CMS Installation and Setup Guide. For instructions on adding additional instances, see section "Step 4. Add New Policy Rules" in the same chapter.



RevocationConstraints Plug-in Module


The RevocationConstraints plug-in module implements the revocation constraints policy. This policy 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. For example, if you don't want to allow revocation of expired certificates in your PKI setup, you can configure the server accordingly using the policy.

During installation, Certificate Management System automatically creates an instance of the revocation constraints policy. See "Configuration Parameters of RevocationConstraints".


Configuration Parameters of RevocationConstraints

In the CMS configuration file, the RevocationConstraints module is identified as <subsystem>.Policy.impl.RevocationConstraints.class=
com.netscape.certsrv.policy.RevocationConstraints, where <subsystem> is ca or ra (prefix identifying the subsystem).

In the CMS window, the module is identified as RevocationConstraints. Figure 3-8 shows how the configurable parameters for the module are displayed in the CMS window.

Figure 3-8    Parameters of the RevocationConstraints module


The configuration shown in Figure 3-8 creates a policy rule named RevokeExpiredClientCert, which specifies that the server should allow revocation of expired client certificates.

Table 3-8 gives details about each of the parameters.


Table 3-8    Description of parameters defined in the RevocationConstraints module  

Parameter

Description

enable  

Specifies whether the rule is enabled or disabled. Check the box to enable the rule (default). Uncheck the box to disable the rule.

  • If you enable the rule and set the remaining parameters correctly, the server verifies the validity period of the certificate being revoked, checks the value assigned to the allowExpiredCerts parameter, and accordingly allows or denies the revocation request.

  • If you disable the rule, the server does not verify the validity period of the certificate being revoked; it simply revokes the certificate.

 

predicate  

Specifies the predicate expression for this rule. If you want the rule to be applied to all certificate requests, leave the field blank (default). To form a predicate expression, see section "Using Predicates in Policy Rules" in Chapter 18, "Setting Up Policies" of CMS Installation and Setup Guide.

Example: HTTP_PARAMS.certType==client  

allowExpiredCerts  

Specifies whether to allow or prevent revocation of expired certificates. Check the box if you want the server to revoke expired certificates (default). Uncheck the box if you don't want the server to revoke expired certificates.  


RevocationConstraintsRule Rule

The rule named RevocationConstraintsRule is an instance of the RevocationConstraints module. Certificate Management System automatically creates this rule during installation. By default, the rule is configured as follows:

  • The rule is enabled.

  • The predicate expression is left blank so that the policy is applied to all certificate revocation requests processed by the server.

  • The server allows revocation of expired certificates.

For details on individual parameters defined in the rule, see Table 3-8. You need to review this rule and make the changes appropriate for your PKI setup. For instructions, see section "Step 2. Modify Existing Policy Rules" in Chapter 18, "Setting Up Policies" of CMS Installation and Setup Guide. For instructions on adding additional instances, see section "Step 4. Add New Policy Rules" in the same chapter.



RSAKeyConstraints Plug-in Module


The RSAKeyConstraints plug-in module implements the RSA key constraints policy. This policy imposes constraints on the following:

  • The minimum and maximum sizes for keys

  • The exponent sizes

The policy restricts the key size to one of the sizes supported by Certificate Management System—512, 1024, 2048, or 4096. In other words, the policy allows you to set up restrictions on the lengths of public keys certified by Certificate Management System.

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, Certificate Management System automatically creates an instance of the RSA key constraints policy. See "RSAKeyRule Rule".


Configuration Parameters of RSAKeyConstraints

In the CMS configuration file, the RSAKeyConstraints module is identified as <subsystem>.Policy.impl.RSAKeyConstraints.class=
com.netscape.certsrv.policy.RSAKeyConstraints, where <subsystem> is ca or ra (prefix identifying the subsystem).

In the CMS window, the module is identified as RSAKeyConstraints. Figure 3-9 shows how the configurable parameters for the module are displayed in the CMS window.

Figure 3-9    Parameters of the RSAKeyConstraints module


The configuration shown in Figure 3-9 creates a policy rule named RSAKeySizeForClientCert, which enforces a rule that the server should restrict the minimum and maximum key sizes for all RSA key-based client certificates to 512 and 2048, respectively.

Table 3-9 describes each parameter.


Table 3-9    Description of parameters defined in the RSAKeyConstraints module  

Parameter

Description

enable  

Specifies whether the rule is enabled or disabled. Check the box to enable the rule (default). Uncheck the box to disable the rule.

  • If you enable the rule and set the remaining parameters correctly, the server uses the configured RSA key rules when issuing certificates specified by the predicate parameter.

  • If you disable the rule, the server certifies the requested key size.

 

predicate  

Specifies the predicate expression for this rule. If you want the rule to be applied to all certificate requests, leave the field blank (default). To form a predicate expression, see section "Using Predicates in Policy Rules" in Chapter 18, "Setting Up Policies" of CMS Installation and Setup Guide.

Example: HTTP_PARAMS.certType==client  

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.

In general, a longer key size results in a key pair that is more difficult to crack. You may want to allow a minimum length to ensure a minimum level of security.

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.

Example: 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.

Example: 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 Netscape 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.

Example: 17,65537  


RSAKeyRule Rule

The rule named RSAKeyRule is an instance of the RSAKeyConstraints module. Certificate Management System automatically creates this rule during installation. By default, the rule is configured as follows:

  • The rule is disabled; for the rule to be effective, it must be enabled and configured appropriately.

  • The predicate expression is left blank so that the rule is applied to all certificate enrollment and renewal requests processed by the server.

  • The minimum key size permitted for certificates is 512 bits (minSize=512).

  • The maximum key size permitted for certificates is 2048 bits (maxSize=2048).

  • The exponents allowed are 3, 7, 17, and 65537 (exponents=3,7,17,65537).

For details on individual parameters defined in the rule, see Table 3-9. You need to review this rule and make the changes appropriate for your PKI setup. For instructions, see section "Step 2. Modify Existing Policy Rules" in Chapter 18, "Setting Up Policies" of CMS Installation and Setup Guide. For instructions on adding additional instances, see section "Step 4. Add New Policy Rules" in the same chapter.



SigningAlgorithmConstraints Plug-in Module


The SigningAlgorithmConstraints plug-in module implements the signing algorithm constraints policy. This policy restricts the requested signing algorithm to be one of the algorithms supported by Certificate Management System: 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, Certificate Management System automatically creates an instance of the signing algorithm constraints policy. See "SigningAlgRule Rule".


Configuration Parameters of SigningAlgorithmConstraints

In the CMS configuration file, the SigningAlgorithmConstraints module is identified as <subsystem>.Policy.impl.SigningAlgorithmConstraints.class
=com.netscape.certsrv.policy.SigningAlgorithmConstraints, where <subsystem> is ca or ra (prefix identifying the subsystem).

In the CMS window, the module is identified as SigningAlgorithmConstraints. Figure 3-10 shows how the configurable parameters for the module are displayed in the CMS window.

Figure 3-10    Parameters of the SigningAlgorithmConstraints module


The configuration shown in Figure 3-10 creates a policy rule named SigningAlgForClientCert, which enforces a rule that the server should use MD5 with RSA signature algorithm to sign all client certificates.

Table 3-10 provides details for each of these parameters.


Table 3-10    Description of parameters defined in the SigningAlgorithmConstraints module  

Parameter

Description

enable  

Specifies whether the rule is enabled or disabled. Check the box to enable the rule (default). Uncheck the box to disable the rule.

  • If you enable the rule and set the remaining parameters correctly, the server uses the configured algorithms to sign certificates specified by the predicate parameter.

  • If you disable the rule, the server uses the default algorithm specified for the Certificate Manager; see Certificate Manager's "General Settings" tab in the CMS window.

 

predicate  

Specifies the predicate expression for this rule. If you want the rule to be applied to all certificate requests, leave the field blank (default). To form a predicate expression, see section "Using Predicates in Policy Rules" in Chapter 18, "Setting Up Policies" of CMS Installation and Setup Guide.

Example: HTTP_PARAMS.certType==client  

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.

Example: MD5withRSA  


SigningAlgRule Rule

The rule named SigningAlgRule is an instance of the SigningAlgorithmConstraints module. Certificate Management System automatically creates this rule during installation. By default, the rule is configured as follows:

  • The rule is enabled.

  • The predicate expression is left blank so that the rule is applied to all certificate enrollment and renewal requests processed by the server.

  • The signature algorithms allowed are MD5 with RSA, MD2 with RSA, and SHA-1 with RSA (algorithms=MD5withRSA,MD2withRSA,SHA1withRSA).

For details on individual parameters defined in the rule, see Table 3-10. You need to review this rule and make the changes appropriate for your PKI setup. For instructions, see section "Step 2. Modify Existing Policy Rules" in Chapter 18, "Setting Up Policies" of CMS Installation and Setup Guide. For instructions on adding additional instances, see section "Step 4. Add New Policy Rules" in the same chapter.



SubCANameConstraints Plug-in Module


The SubCANameConstraints plug-in module implements the subordinate CA name constraints policy. This policy 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. The reason for this is that, whenever the Certificate Manager issues a certificate, it stores the related information in its internal database; see Chapter 12, "Setting Up Internal Database" of CMS Installation and Setup Guide. 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, Certificate Management System automatically creates an instance of the subordinate CA name constraints policy. See "SubCANameConstraints Rule".


Configuration Parameters of SubCANameConstraints

In the CMS configuration file, the SubCANameConstraints module is identified as ca.Policy.impl.SubCANameConstraints.class=
com.netscape.certsrv.policy.SubCANameConstraints.

In the CMS window, the module is identified as SubCANameConstraints. Figure 3-11 shows how configurable parameters for the module are displayed in the CMS window.

Figure 3-11    Parameters of the SubCANameConstraints module


The configuration shown in Figure 3-11 creates a policy rule named IssuerDNCheckForSubCACert, which enforces a rule that the server should reject subordinate CA certificate requests with issuer DNs matching its own issuer DN.

Table 3-11 gives details about each of the parameters.


Table 3-11    Description of parameters defined in the SubCANameConstraints module  

Parameter

Description

enable  

Specifies whether the rule is enabled or disabled. Check the box to enable the rule. Uncheck the box to disable the rule (default).

  • If you enable the rule and set the remaining parameters correctly, the server checks the certificate requests for issuer name uniqueness. If a certificate with the requested issuer name already exists in the internal database, the server rejects the request.

  • If you disable the rule, the server does not check the CA certificate requests for issuer name uniqueness.

 

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 section "Using Predicates in Policy Rules" in Chapter 18, "Setting Up Policies" of CMS Installation and Setup Guide.

Example: HTTP_PARAMS.certType==ca  


SubCANameConstraints Rule

The rule named SubCANameConstraints is an instance of the SubCANameConstraints module. Certificate Management System automatically creates this rule during installation. By default, the rule is configured as follows:

  • The rule is enabled.

  • The predicate expression is left blank so that the rule is applied to all certificate enrollment and renewal requests processed by the server.

For details on individual parameters defined in the rule, see Table 3-12. You need to review this rule and make the changes appropriate for your PKI setup. For instructions, see section "Step 2. Modify Existing Policy Rules" in Chapter 18, "Setting Up Policies" of CMS Installation and Setup Guide. For instructions on adding additional instances, see section "Step 4. Add New Policy Rules" in the same chapter.



UniqueSubjectNameConstraints Plug-in Module


The UniqueSubjectNameConstraints plug-in module implements the unique subject name constraints policy. This policy 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 Certificate Management System allows you to add this extension to certificates using the key usage extension policy explained in "KeyUsageExt Plug-in Module".

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, Certificate Management System automatically creates an instance of the unique subject name constraints policy. See "UniqueSubjectNameConstraints Rule".


Configuration Parameters of UniqueSubjectNameConstraints

In the CMS configuration file, the UniqueSubjectNameConstraints module is identified as ca.Policy.impl.UniqueSubjectNameConstraints.class=
com.netscape.certsrv.policy.UniqueSubjectNameConstraints.

In the CMS window, the module is identified as UniqueSubjectNameConstraints. Figure 3-12 shows how configurable parameters for the module are displayed in the CMS window.

Figure 3-12    Parameters of the UniqueSubjectNameConstraints module


The configuration shown in Figure 3-12 creates a policy rule named UniqueNameForAllCert, which enforces a rule that all certificates must have unique subject names.

Table 3-12 describes each of the parameters.


Table 3-12    Description of parameters defined in the UniqueSubjectNameConstraints module  

Parameter

Description

enable  

Specifies whether the rule is enabled or disabled. Check the box to enable the rule. Uncheck the box to disable the rule (default).

  • If you enable the rule and set the remaining parameters correctly, the server checks the certificate requests, as specified by the predicate parameter, for subject name uniqueness.

  • If you disable the rule, the server does not check the certificate requests for subject name uniqueness.

 

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 section "Using Predicates in Policy Rules" in Chapter 18, "Setting Up Policies" of CMS Installation and Setup Guide.

Example: HTTP_PARAMS.certType==client  

enablePreAgentApprovalChecking  

Specifies whether the request must be checked for the subject name uniqueness on submission by the user, before the request gets queued for agent approval.

  • Check the box if you want the server to check the certificate request for the subject name uniqueness as soon as the user submits it.

  • Uncheck the box 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 Plug-in Module") before determining whether to issue the certificate.

 

enableKeyUsageExtensionChecking  

Specifies whether the certificate request must be checked for the Key Usage extension. Note that the policy can check the certificate request for the Key Usage extension only if you uncheck (disable) the enablePreAgentApprovalChecking parameter. The reason for this is that, extensions are set on the request after agent approval, so this checking can be done after an agent approves the request.

  • Check the box if you want the server to check the certificate request for the Key Usage extension. If you check the box, 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; see section "Step 5. Reorder Policy Rules" in Chapter 18, "Setting Up Policies" of CMS Installation and Setup Guide.)

  • Uncheck the box if you don't want the server to check the certificate request for the Key Usage extension. If you uncheck the box, 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.

 


UniqueSubjectNameConstraints Rule

The rule named UniqueSubjectNameConstraints is an instance of the UniqueSubjectNameConstraints module. Certificate Management System automatically creates this rule during installation. By default, the rule is configured as follows:

  • The rule is disabled; for the rule to be effective, it must be enabled and configured appropriately.

  • The certificate requests are checked for subject name uniqueness after agents process the requests for approval—if you're using manual enrollment and deferred requests.

  • The certificate requests are checked for Key Usage extension.

  • The predicate expression is left blank so that the rule is applied to all certificate enrollment and renewal requests processed by the server.

For details on individual parameters defined in the rule, see Table 3-12. You need to review this rule and make the changes appropriate for your PKI setup. For instructions, see section "Step 2. Modify Existing Policy Rules" in Chapter 18, "Setting Up Policies" of CMS Installation and Setup Guide. For instructions on adding additional instances, see section "Step 4. Add New Policy Rules" in the same chapter.



ValidityConstraints Plug-in Module


The ValidityConstraints plug-in module implements the validity constraints policy. This policy 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.

Note When applying the validity constraints policy, the server does not check the lag time in all certificate requests. It checks the lag time only in those requests that are based on the CRMF protocol—currently, CRMF is the only enrollment format that allows an end entity to request a specific validity period with the notBefore attribute set to a time in the past.


You may apply this policy to end-entity certificate enrollment requests. It can be useful to restrict the length of the validity period for certificates issued by the server. For example, if you want users to renew their certificates at least once a year, you can set the maximum validity period to one year. If you want to limit the frequency of certificate renewals to keep down administrative costs, you can set the minimum validity period to six months.

By default, any validity requested in a certificate enrollment request cannot exceed beyond that of the expiration time specified in the CA's signing certificate. If the Certificate Manager (CA) finds a request with validity period extending beyond that of its CA signing certificate, it automatically truncates the validity period to end on the day the CA signing certificate expires. For example, if the CA signing certificate expires on June 10, 2004, any enrollment request with validity period beyond June 10, 2004 will have validity period truncated to end on June 10, 2004.

However, you can configure the Certificate Manager to issue certificates with validity periods beyond that of its CA signing certificate by selecting the "Override validity nesting requirement" option; see section "Step 6. Enable End-Entity Interaction" in Chapter 18, "Setting Up Policies" of CMS Installation and Setup Guide.

During installation, Certificate Management System automatically creates an instance of the validity constraints policy. See "DefaultValidityRule Rule".


Configuration Parameters of ValidityConstraints

In the CMS configuration file, the ValidityConstraints module is identified as <subsystem>.Policy.impl.ValidityConstraints.class=
com.netscape.certsrv.policy.ValidityConstraints, where <subsystem> is ca or ra (prefix identifying the subsystem).

In the CMS window, the module is identified as ValidityConstraints. Figure 3-13 shows how configurable parameters for the module are displayed in the CMS window.

Figure 3-13    Parameters of the ValidityConstraints module


The configuration shown in Figure 3-13 creates a policy rule named ValidityForClientCert, which enforces a rule that all client certificates requested by end users in an organizational unit (OU) called Marketing are valid for at least 60 days (two months) and require renewing after 180 days (six months).

Table 3-13 gives details about each of the parameters.


Table 3-13    Description of parameters defined in the ValidityConstraints module  

Parameter

Description

enable  

Specifies whether the rule is enabled or disabled. Check the box to enable the rule (default). Uncheck the box to disable the rule.

  • If you enable the rule and set the remaining parameters correctly, the server sets the configured validity period in certificates specified by the predicate parameter.

  • If you disable the rule, the server does not set the configured validity period in certificates; it sets the validity period to the one specified in the request.

 

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 section "Using Predicates in Policy Rules" in Chapter 18, "Setting Up Policies" of CMS Installation and Setup Guide.

Example: HTTP_PARAMS.certType==client AND HTTP_PARAMS.OU==Marketing  

minValidity  

Specifies the minimum validity period, in days, for certificates.

Permissible values: An integer greater than zero and less than the value specified by the maxValidity parameter. The default value is 180 days.

Example: 60  

maxValidity  

Specifies the maximum validity period, in days, for certificates.

Permissible values: An integer greater than zero and also greater than the value specified by the minValidity parameter. The default value is 730 days.

Example: 180  

leadTime  

Specifies the lead time, in minutes, for certificates. For a certificate renewal request to pass the renewal validity constraints policy, the value of the notBefore attribute in the certificate request must not be more than value of the leadTime parameter in the future, relative to the time when the policy rule is run.

The notBefore attribute value specifies the date on which the certificate validity begins; validity dates through the year 2049 are encoded as UTCTime, dates in 2050 or later are encoded as GeneralizedTime.

Permissible values: As applicable. The default value is 10 minutes.

Example: 10  

lagTime  

Specifies the lag time, in minutes, for certificates. For a certificate renewal request to pass the renewal validity constraints policy, the value of the notBefore attribute in the certificate request must not be more than the value of the lagTime in the past, relative to the time when the policy is run.

The notBefore attribute value specifies the date on which the certificate validity ends; validity dates through the year 2049 are encoded as UTCTime, dates in 2050 or later are encoded as GeneralizedTime.

Permissible values: As applicable. The default value is 10 minutes.

Example: 10  

notBeforeSkew  

Specifies the number of minutes to subtract from the current time when creating the value for the certificate's notBefore attribute. It can help some clients with incorrectly set clocks use the new certificate after downloading. For example, if the certificate is issued at 11:30 a.m. and the clock settings of the client into which the certificate is downloaded is 11:20 a.m., the certificate cannot be used for 10 minutes. Setting the value of the beforeFix parameter to 10 minutes would adjust the value of the notBefore parameter to 11:20 a.m.—thus making the certificate usable following the download.

Permissible values: As applicable. The default value is 5 minutes.

Example: 5  


DefaultValidityRule Rule

The rule named DefaultValidityRule is an instance of the ValidityConstraints module. Certificate Management System automatically creates this rule during installation. By default, the rule is configured as follows:

  • The rule is enabled.

  • The predicate expression is left blank so that the rule is applied to all certificate enrollment and renewal requests processed by the server.

  • The minimum validity period allowed for certificates is 1 day (minValidity=1).

  • The maximum validity period allowed for certificates is 365 days (maxValidity=365).

  • The lead time allowed is 10 minutes (leadTime=10).

  • The lag time allowed is 10 minutes (lagTime=10).

  • The the number of minutes to subtract from the current time when creating the value for the certificate's notBefore attribute is 5 minutes (notBeforeSkew=5).

For details on individual parameters defined in the rule, see Table 3-13. You need to review this rule and make the changes appropriate for your PKI setup. For instructions, see section "Step 2. Modify Existing Policy Rules" in Chapter 18, "Setting Up Policies" of CMS Installation and Setup Guide. For instructions on adding additional instances, see section "Step 4. Add New Policy Rules" in the same chapter.


Previous     Contents     Index     Next     
Copyright © 2001 Sun Microsystems, Inc. Some preexisting portions Copyright © 2001 Netscape Communications Corp. All rights reserved.

Last Updated April 02, 2001