|
Chapter 17
Constraints-Specific Policy Modules
You can configure Certificate Management System 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 "Extension-Specific Policy 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 17.1) lists all the modules that are registered with a CMS instance.
Figure 17.1 CMS window showing policy modules registered with a Certificate Manager 
Table 17.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:
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 "Policy Processor". 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.
|
| DSA Key Constraints Policy |
|
The DSAKeyConstraints plug-in module implements the DSA key constraints policy. This policy imposes constraints on the following:
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".
DSAKeyConstraints Module
The Java class that implements the DSA key constraints policy is as follows:
com.netscape.certsrv.policy.DSAKeyConstraints
Figure 17.2 shows how configurable parameters for the DSAKeyConstraints module are displayed in the CMS window.
Figure 17.2 Parameters of the DSAKeyConstraints module 
The configuration shown in Figure 17.2 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 17.2 describes each of the parameters.
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:
For details on individual parameters defined in the rule, see Table 17.2. You need to review this rule and make the changes appropriate for your PKI setup. For instructions, see "Step 2. Modify Existing Policy Rules". For instructions on adding additional instances, see "Step 4. Add New Policy Rules".
|
| Issuer Constraints Policy |
|
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".
IssuerConstraints Module
The name of the Java class that implements the issuer constraints policy is as follows:
com.netscape.certsrv.policy.IssuerConstraints
Figure 17.3 shows how the configurable parameters for the IssuerConstraints module are displayed in the CMS window.
Figure 17.3 Parameters of the IssuerConstraints module 
The configuration shown in Figure 17.3 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 17.3 describes each parameter.
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:
For details on individual parameters defined in the rule, see Table 17.3. You need to review this rule and make the changes appropriate for your PKI setup. For instructions, see "Step 2. Modify Existing Policy Rules". For instructions on adding additional instances, see "Step 4. Add New Policy Rules".
|
| Key Algorithm Constraints Policy |
|
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".
KeyAlgorithmConstraints Module
The name of the Java class that implements the key algorithm constraints policy is as follows:
com.netscape.certsrv.policy.KeyAlgorithmConstraints
Figure 17.4 shows how the configurable parameters for the KeyAlgorithmConstraints module are displayed in the CMS window.
Figure 17.4 Parameters of the KeyAlgorithmConstraints module 
The configuration shown in Figure 17.4 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 17.4 gives details about each of the parameters.
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:
For details on individual parameters defined in the rule, see Table 17.4. You need to review this rule and make the changes appropriate for your PKI setup. For instructions, see "Step 2. Modify Existing Policy Rules". For instructions on adding additional instances, see "Step 4. Add New Policy Rules".
|
| PIN Present Policy |
|
The PinPresentConstraints plug-in module implements the PIN present policy. This policy checks for the presence of a user's PIN in the authentication directory and accordingly allows or rejects the certificate request. This policy enables you to effectively deploy one of the directory-based enrollment methods, the password and PIN-based enrollment with PIN removal, by restricting users from enrolling for multiple certificates. For details, see "Setting Up Authentication for End-User Enrollment".
In the password and PIN-based enrollment method, users enroll for a certificate using their directory user ID, password and PIN. After a PIN has been used to successfully authenticate a user, the Certificate Manager calls the PinRemovalListener module. This module removes the PIN from the authentication directory when the Certificate Manager issues the requested certificate.
Note that listeners in Certificate Management System are objects which register themselves as interested in knowing about certain events--for example, change in the state of a request--and carry out a specific task. For more information on listeners, check the samples directory:
<server_root>/cms_sdk/samples/listeners
Once the PIN is removed from the authentication directory, it prevents the user from enrolling for another certificate.
The above mentioned process works smoothly if a Certificate Manager or Registration Manager is configured to use the master directory for authenticating users. The process may not work smoothly in deployment scenarios that involve replicated directories. In these scenarios, you need to use the PIN present policy to verify that the PIN has been removed from the directory. Here's an example of such a scenario:
A Registration Manager acts as an enrollment authority, passing authenticated certificate requests to a Certificate Manager; the users have no direct interaction with the Certificate Manager. The Certificate Manager (CA) and the master corporate directory are behind the firewall. The Registration Manager and a replica of the corporate directory are outside the firewall. The Certificate Manager is configured to communicate with the master corporate directory. The Registration Manager has read-only permission to the replicated corporate directory, and it uses the directory for authenticating end entities. Both the Certificate Manager and Registration Manager are configured for password and PIN-based enrollment with the PIN removal feature turned on. The master corporate directory is configured to update its replica (outside the firewall) every 10 minutes.
When a user enrolls for a certificate request using the End Entity Service interface of the Registration Manager, it authenticates the user against the replica of the corporate directory. If the user presents a valid user ID, password and PIN, the Registration Manager authenticates the user successfully and forwards the request to the Certificate Manager. As the Registration Manager is configured for PIN-based enrollment with PIN removal, it attempts to remove the PIN from the directory, but it can't as it has no write permission to the replicated directory; the PIN is still around.
When the Certificate Manager processes the request forwarded by the Registration Manager, it calls the PinRemovalListener module, which in turn removes the PIN from the master corporate directory when the Certificate Manager issues the certificate. (The Certificate Manager sends the certificate to the Registration Manager, which in turn sends it to the user.)
Although the CA has removed the PIN from the master directory, the replicated directory still has the PIN, because the update hasn't occurred. In the meantime, the user may enroll again successfully (from the Registration Manager) for another certificate and receive it from the Certificate Manager.
The PIN present policy enables you to prevent users from successfully enrolling for multiple certificates from the Registration Manager during the time interval between directory updates. If you configure the CA to use this policy to check the master directory for PINs before issuing certificates, successive certificate requests would fail because the PIN has been removed from the master directory. This way, even if the Registration Manager authenticates successive request, the Certificate Manager rejects them, thus ensuring that a user has only one certificate.
Unlike some of the other policy modules, Certificate Management System does not create an instance of the PIN present policy during installation. If you want a Certificate Manager or Registration Manager to check for PINs, you must create an instance of the PinPresentConstraints module and configure it. For instructions, see "Step 3. Enable the PIN Present Policy".
PinPresentConstraints Module
The Java class that implements the PIN present policy is as follows:
com.netscape.certsrv.policy.PinPresentConstraints
Figure 17.5 shows how the configurable parameters for the PinPresentConstraints module are displayed in the CMS window.
Figure 17.5 Parameters of the PinPresentConstraints module 
The configuration shown in Figure 17.5 creates a policy rule named PinCheckForClientCert, which specifies that the server should check the configured authentication directory for PINs before issuing a client certificate. To locate the user's PIN attribute in the directory, the server should start the search from the O=siroe.com node.
Table 17.5 gives details about each of the parameters.
|
| Renewal Constraints Policy |
|
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 "Renewal Validity Constraints Policy") 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".
RenewalConstraints Module
The Java class that implements the renewal constraints policy is as follows:
com.netscape.certsrv.policy.RenewalConstraints
Figure 17.6 shows how the configurable parameters for the RenewalConstraints module are displayed in the CMS window.
Figure 17.6 Parameters of the RenewalConstraints module 
The configuration shown in Figure 17.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 17.6 gives details about each of the parameters.
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:
For details on individual parameters defined in the rule, see Table 17.6. You need to review this rule and make the changes appropriate for your PKI setup. For instructions, see "Step 2. Modify Existing Policy Rules". For instructions on adding additional instances, see "Step 4. Add New Policy Rules".
|
| Revocation Constraints Policy |
|
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 "RevocationConstraintsRule Rule".
RevocationConstraints Module
The Java class that implements the revocation constraints policy is as follows:
com.netscape.certsrv.policy.RevocationConstraints
Figure 17.7 shows how the configurable parameters for the RevocationConstraints module are displayed in the CMS window.
Figure 17.7 Parameters of the RevocationConstraints module 
The configuration shown in Figure 17.7 creates a policy rule named RevokeExpiredClientCert, which specifies that the server should allow revocation of expired client certificates.
Table 17.7 gives details about each of the parameters.
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:
For details on individual parameters defined in the rule, see Table 17.7. You need to review this rule and make the changes appropriate for your PKI setup. For instructions, see "Step 2. Modify Existing Policy Rules". For instructions on adding additional instances, see "Step 4. Add New Policy Rules".
|
| Renewal Validity Constraints Policy |
|
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 "Validity Constraints Policy") 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 "Certificate Renewal Notifications".
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:
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; for details, see "Certificate Renewal". 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 "CA Signing Key Pair and 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 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 "Step 6. Enable End-Entity Interaction".
During installation, Certificate Management System automatically creates an instance of the renewal validity constraints policy. See "DefaultRenewalValidityRule Rule".
RenewalValidityConstraints Module
The Java class that implements the renewal validity constraints policy is as follows:
com.netscape.certsrv.policy.RenewalValidityConstraints
Figure 17.8 shows how the configurable parameters for the RenewalValityConstraints module are displayed in the CMS window.
Figure 17.8 Parameters of the RenewalValidityConstraints module 
The configuration shown in Figure 17.8 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 17.8 gives details about each of the parameters.
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:
For details on individual parameters defined in the rule, see Table 17.8. You need to review this rule and make the changes appropriate for your PKI setup. For instructions, see "Step 2. Modify Existing Policy Rules". For instructions on adding additional instances, see "Step 4. Add New Policy Rules".
|
| RSA Key Constraints Policy |
|
The RSAKeyConstraints plug-in module implements the RSA key constraints policy. This policy imposes constraints on the following:
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".
RSAKeyConstraints Module
The Java class that implements the RSA key constraints policy is as follows:
com.netscape.certsrv.policy.RSAKeyConstraints
Figure 17.9 shows how the configurable parameters for the RSAKeyConstraints module are displayed in the CMS window.
Figure 17.9 Parameters of the RSAKeyConstraints module 
The configuration shown in Figure 17.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 17.9 describes each parameter.
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:
For details on individual parameters defined in the rule, see Table 17.9. You need to review this rule and make the changes appropriate for your PKI setup. For instructions, see "Step 2. Modify Existing Policy Rules". For instructions on adding additional instances, see "Step 4. Add New Policy Rules".
|
| Signing Algorithm Constraints Policy |
|
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).
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".
SigningAlgorithmConstraints Module
The Java class that implements the signing algorithm constraints policy is as follows:
com.netscape.certsrv.policy.SigningAlgorithmConstraints
Figure 17.10 shows how the configurable parameters for the SigningAlgorithmConstraints module are displayed in the CMS window.
Figure 17.10 Parameters of the SigningAlgorithmConstraints module 
The configuration shown in Figure 17.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 17.10 provides details for each of these parameters.
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:
For details on individual parameters defined in the rule, see Table 17.10. You need to review this rule and make the changes appropriate for your PKI setup. For instructions, see "Step 2. Modify Existing Policy Rules". For instructions on adding additional instances, see "Step 4. Add New Policy Rules".
|
| Subordinate CA Name Constraints Policy |
|
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 "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, Certificate Management System automatically creates an instance of the subordinate CA name constraints policy. See "SubCANameConstraints Rule".
SubCANameConstraints Module
The Java class that implements the subordinate CA name constraints policy is as follows:
com.netscape.certsrv.policy.SubCANameConstraints
Figure 17.11 shows how configurable parameters for the SubCANameConstraints module are displayed in the CMS window.
Figure 17.11 Parameters of the SubCANameConstraints module 
The configuration shown in Figure 17.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 17.11 gives details about each of the parameters.
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:
For details on individual parameters defined in the rule, see Table 17.12. You need to review this rule and make the changes appropriate for your PKI setup. For instructions, see "Step 2. Modify Existing Policy Rules". For instructions on adding additional instances, see "Step 4. Add New Policy Rules".
|
| Unique Subject Name Constraints Policy |
|
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 "Key Usage Extension Policy".
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".
UniqueSubjectNameConstraints Module
The Java class that implements the unique subject name constraints policy is as follows:
com.netscape.certsrv.policy.UniqueSubjectNameConstraints
Figure 17.12 shows how configurable parameters for the UniqueSubjectNameConstraints module are displayed in the CMS window.
Figure 17.12 Parameters of the UniqueSubjectNameConstraints module 
The configuration shown in Figure 17.12 creates a policy rule named UniqueNameForAllCert, which enforces a rule that all certificates must have unique subject names.
Table 17.12 describes each of the parameters.
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:
For details on individual parameters defined in the rule, see Table 17.12. You need to review this rule and make the changes appropriate for your PKI setup. For instructions, see "Step 2. Modify Existing Policy Rules". For instructions on adding additional instances, see "Step 4. Add New Policy Rules".
|
| Validity Constraints Policy |
|
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:
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 (see "CA Signing Key Pair and 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 "Step 6. Enable End-Entity Interaction".
During installation, Certificate Management System automatically creates an instance of the validity constraints policy. See "DefaultValidityRule Rule".
ValidityConstraints Module
The Java class that implements the validity constraints policy is as follows:
com.netscape.certsrv.policy.ValidityConstraints
Figure 17.13 shows how configurable parameters for the ValidityConstraints module are displayed in the CMS window.
Figure 17.13 Parameters of the ValidityConstraints module 
The configuration shown in Figure 17.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 17.13 gives details about each of the parameters.
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:
For details on individual parameters defined in the rule, see Table 17.13. You need to review this rule and make the changes appropriate for your PKI setup. For instructions, see "Step 2. Modify Existing Policy Rules". For instructions on adding additional instances, see "Step 4. Add New Policy Rules".
|
|
|
|
|
Previous
