Netscape logo Administrator's Guide
Netscape Certificate Management System
Previous      Contents      Index      DocHome      Next     

Chapter 15   Revocation and CRLs


Netscape Certificate Management System (CMS) provides methods for revoking certificates and for producing lists of revoked certificates, called certificate revocation lists (CRLs). This chapter describes the methods for revoking a certificate, describes CMC Revocation, and provides details about CRLs and setting up CRLs.

This chapter contains the following sections:

Revocation

Certificates can be revoked by an end user (the original owner of the certificate), a server administrator, or by a Certificate Manager agent. End users can revoke certificates by using the Revocation form provided in the end-entity services interface. Agents can revoke end-entity certificates by using the appropriate form in the Agent Services interface. Certificate-based (SSL client authentication) or challenge-password-based authentication is required in both cases.

Upon receiving the list of certificates to be revoked, the Registration Manager creates a CMMF request and sends it to the Certificate Manager. The Certificate Manager marks the corresponding certificate records in its internal database as revoked, and if configured to do so, removes the revoked certificates from the publishing directory and updates the CRL in the publishing directory.

Authentication of End Users During Certificate Revocation

When an end user submits a certificate revocation request, the first step in the revocation process is for the Certificate Manager or Registration Manager to identify and authenticate the end user to verify that the user is attempting to revoke his or her own certificate, not a certificate belonging to someone else.

Both the Certificate Manager and Registration Manager support the SSL Client Authenticated Revocation and the Challenge-Password-Based Revocation.

SSL Client Authenticated Revocation

In an SSL client authenticated revocation method, the server expects the end user to present a certificate that has the same subject name as the one they wants to revoke and uses that for authentication purposes. The server verifies the authenticity of a revocation request by mapping the subject name in the certificate being presented for client authentication to certificates in its internal database. The server revokes the certificate only if the certificate maps successfully to one or more valid or expired certificates in its internal database.

After successful authentication, if the server detects only one valid or expired certificate with matching subject name as that of the one presented for client authentication, it revokes the certificate. If the server detects more than one valid or expired certificate with matching subject name, it lists all those certificates. The user can then either select the certificate to be revoked or revoke all certificates in the list.

Challenge-Password-Based Revocation

A challenge password is a unique, alphanumeric string that the end user specifies when requesting a certificate; the user is expected to keep this password confidential and use it to authenticate to the server when revoking the certificate. When the server issues the certificate, it associates the password with the certificate, stores both the certificate and password in its internal database, and uses them later for authenticating any revocation requests.

In the challenge-password-based revocation method, the server expects the end user to specify the serial number of the certificate the user wants to revoke and the challenge password associated with the certificate. The server verifies the authenticity of a revocation request by mapping the serial number to the list of certificates in its internal database followed by mapping the challenge password specified to the one associated with the matching certificate it detects in the internal database.

Challenge passwords can only be set up with the agent-approved authentication method. The form associated with the agent-approved authentication is the only form that contains this capability.

The server revokes the certificate only if the certificate maps successfully to a valid or expired certificates in its internal database. If the server detects a valid or expired certificate with a matching serial number and challenge password, it automatically revokes the certificate.

Certificate Revocation Forms

The end-entity services interface of the Certificate Manager and Registration Manager includes default HTML forms for both the SSL client authenticated revocation and challenge-password-based revocation. The forms are accessible from the Revocation tab. You can view the form that enables SSL client authenticated revocation by clicking the User Certificate link.

If you want to change the forms to suit your organization's requirements, you can edit the following files:

Both the files are located in the following directory: <server_root>/cert-<instance_id>/web-apps/ee/<subsystem>/

For details on individual form elements, see the online help available by clicking the Help button on the form. For more information on customizing the form, see CMS Customization Guide.

CMCRevocation

Note: The revocation method described here will return Javascript rather than a CMC response. This information has been deprecated. See Setting Up a CMC Client for the latest information.

CMC revoke allows you to set up your own revocation client, sign the revocation request with an agent certificate, and then send the signed request to the Certificate Manager. The enabled instance of the CMCAuth plug-in module also activates CMC revoke when it is enabled (the default). When this method is setup, the Certificate Manager will automatically issue certificates when a valid certificate request signed with the agent's certificate is received, and will automatically revoke a certificate when a valid revocation request signed with the agent's certificate is received.

Setting Up CMC Revocation

To set up CMC revoke you do the following:

CMC Revoke Utility

The CMC Revoke utility, CMCRevoke, is used to sign a revocation request with an agent's certificate. It is installed along with CMS and is available from the following directory:

<server_root>/bin/cert/tools

This utility has the following syntax:

CMCRevoke -d<dir to cert8.db, key3.db> -n<nickname> -i<issuerName> -s<serialName> -m<reason to revoke> -c<comment>

where

-d

The directory where cert8.db, key3.db, and secmod.db containing the agent certificate are located.

-n

The nickname of the agent's certificate.

-i

The issuer name of the certificate being revoked.

-s

The serial number of the certificate being revoked in decimal value.

-m

The reason the certificate is being revoked. Specify the reason code by providing the number associated with the revocation reason from the following:

0 = Unspecified

1 = Key compromised

2 = CA key compromised

3 = Affiliation changed

4 = Certificate superseded

5 = Cessation of operation

6 = Certificate is on hold

-c

Include any comments about the request.

Note: Surround values that include spaces in quotation marks.

Testing CMC Revoke

  1. Go to the following directory:
    2. <server_root>/bin/cert/tools
     
  2. Create a CMC revocation request for a certificate that exists.
    3. .\CMCRevoke -d<dir to cert8.db, key3.db> -n<nickname> -i<issuerName> -s<serialName> -m<reason to revoke> -c<comment>
     
    For example, if the directory containing the agent certificate is .netscape, the nickname of the certificate is RegistartionManagerAgentCert, and the serial number of the certificate is 22, the command would look like this:
     
    .\CMCRevoke -d".\.netscape" -n"RegistartionManagerAgentCert" -i"cn=agentAuthMgr" -s22 -m0 -c"test comment"
     
  3. Go to the end entity interface at the following URL:
    4. https://localhost/ca/
     
  4. Select the Revocation Tab.
  5. Select the CMC Revoke link on the menu.
  6. Paste the output of step 2 into the text area
    7. Remove "-----BEGIN NEW CERTIFICATE REQUEST-----" and "----END NEW CERTIFICATE REQUEST-----" from the pasted content.
     
  7. Click Submit.
  8. Verify that the returned page confirms that the certificate 22 has been revoked.

About CRLs

Server and client applications that use public-key certificates as tokens of identification need access to information about the validity of a certificate; because one of the factors that determines the validity of a certificate is its revocation status, these applications need to know whether the certificate being validated has been revoked. In that regard, the CA has a responsibility to do the following:

Whenever a certificate is revoked the Certificate Manager automatically updates the status of the certificate in its internal database—it marks the copy of the certificate in its internal database as revoked and removes the revoked certificate from the publishing directory, if the Certificate Manager is configured to remove the certificate from the database.

One of the standard methods for conveying the revocation status of certificates is by publishing a list of revoked certificates. This list is known as a certificate revocation list (CRL). A CRL is a publicly available list of certificates that have been revoked.

You can configure the Certificate Manager to generate CRLs by enabling and configuring the CRL feature. You can also create CRLs conforming to X.509 (either version 1 or version 2) standards by enabling extension-specific modules in the CRL configuration—version 1 CRLs do not use extensions, version 2 CRLs use extensions. Note that the server supports standard CRL extensions through its CRL issuing points framework, see "Setting CRL Extensions"" for more information on setting up CRL extensions for issuing points. You can configure the Certificate Manager to generate the CRL every time a certificate is revoked and at periodic intervals which is stored in its internal database. If you configure the publishing feature, you can also publish the CRLs to a file, an LDAP directory, or an OCSP responder.

Note that the Registration Manager cannot create or publish CRLs, although it can take revocation requests and pass them on to the Certificate Manager.

A CRL is issued and digitally signed by the CA that issued the certificates listed in the CRL. The CA may use a single key pair to sign both the certificates and CRLs it issues or two separate key pairs, one for signing certificates and another one for signing CRLs.

By default, the Certificate Manager uses a single key pair for signing the certificates it issues and CRLs it generates. You may choose to create another key pair for the Certificate Manager and use it exclusively for signing the CRLs it generates. See "Getting a CRL Signing Key Pair and Certificate" for details on setting this up.

Reasons for Revoking a Certificate

A Certificate Manager can revoke any certificate it has issued. There are generally accepted reason codes for revoking a certificate that are often included in the CRL. These include the following:

0 = Unspecified—No particular reason is given.

1 = Key Compromised—The private key associated with the certificate has been compromised in some way.

2 = CA Key Compromised—The private key associated with the CA that issued this certificate has been compomised in some way.

3 = Affiliation Changed—The owner of the certificate is no longer affiliated with the issuer of the certificate, and either no longer has rights to the access gained with the certificate or no longer needs it.

4 = Certificate Superseded—Another certificate replaces the use of this one.

5 = Cessation of Operation—The CA that issued the certificate ceases to operate.

6 = Certificate is on Hold—The certificate is on hold pending further action. It is treated as revoked, but may be taken off hold in the future.

A certificate can be revoked by administrators, agents, and end entities. Agents and administrators (with agent privileges) can revoke certificates by using the forms provided in the agent interface. End users can revoke certificates by using the forms provided in the Revocation tab of the end-entity interface. Note that end users can revoke only their own certificates, whereas agents and administrators can revoke any certificates issued by the server. End users are also required to authenticate to the server in order to revoke their certificate.

Whenever a certificate is revoked, the Certificate Manager updates the status of the certificate in its internal database. This way, the server keeps track of all revoked certificates in its internal database and, when configured, it makes the revoked list of certificates public (by publishing it to a central repository) to notify other users that the certificates in the list are no longer valid.

Revocation Checking by Netscape Servers

Because Netscape servers currently cannot check the revocation status of a certificate, you should use other forms of access control. For example, you can remove individual users from access groups to prevent them from accessing the server.

Because CMS can check the revocation status of the certificates that it issues, you do not need to rely on other forms of access control.

Publishing of CRLs

The Certificate Manager can publish the CRL to a file, an LDAP-compliant directory, or to an OCSP responder. You can set up publishing to one, or all of these methods, and configure how often updates are made.

For information about setting up publishing to any of these methods, see Chapter 16 "Publishing."

For information on setting up an OCSP responder, see Chapter 5 "OCSP Responder."

CRL Issuing Points

Because CRLs can grow very large, several methods have been developed to minimize the overhead of retrieving and delivering large CRLs. One of these methods is based on partitioning the entire certificate space and associating a separate CRL with every partition. This partition is called a CRL issuing point—it is the location where a subset of all the revoked certificates are maintained. Partitioning can be based on whether the revoked certificate is a CA certificate or end-entity certificate. Each issuing point is identified by its name.

Once the issuing points have been defined, they can be included in certificates so that an application that needs to check the revocation status of a certificate can access the CRL issuing points specified in the certificate instead of the master or main CRL—the application would check the CRL maintained at the issuing point, which would be smaller in size compared to the master CRL, and thus speed up the revocation-status-checking process.

CRL distribution points can be associated with certificates by setting the CRLDistributionPoint extension in them.

By default, the Certificate Manager only generates and publishes a single CRL, identified as the master CRL. You can also define an issuing point for CA signing certificates, and an issuing point that includes all revoked certificate information including expired certificates.

Delta CRLs

You can issue Delta CRLs for any issuing point defined. A delta CRL will contain information about any certificates revoked since the last update to the full CRL. You set up Delta CRLs for an issuing point by enabling the DeltaCRLIndicator extension.

How CRLs Work

You set up the generation of CRLs by specifying issuing points, configuring those issuing points, and setting up CRL extensions, if desired.

When the CRL feature is enabled by enabling one or more issuing points, the server collects revocation information as certificates are revoked. The server attempts to match the revoked certificate against all issuing points that are set up. A given certificate can match none of the issuing points, one of the issuing points, several of the issuing points, or all of the issuing points. When a certificate that has been revoked matches an issuing point, the server stores the information about the certificate in the cache for that issuing point.

The cache is copied to the internal directory at the intervals that you specify for copying the cache. When the interval for creating a CRL is reached, as specified in the configuration for that issuing point, a CRL is created from the cache. If a delta CRL has been set up for this issuing point, a delta CRL is also created at this time. The full CRL contains all revoked certificate information since the Certificate Manager began collecting this information. The delta CRL contains all revoked certificate information since the last update of the full CRL.

The full CRL and the delta CRL have the same number allowing clients to determine a match between them. The delta CRL also contains information about which CRL is the full CRL that this delta records the information since its creation. For example, if the numbering were as simple as 1,2,3, the first CRL would be CRL 1. The second CRL would be CRL 2 and the delta would be deltaCRL 2. The deltaCRL 2 would reference CRL 1 as the full CRL that this delta contains the updates since its issuance.

Note that when changes are made to the extensions for an issuing point, no delta CRL will be created along with the next full CRL that is created for that issuing point. A delta CRL will be created along with the second full CRL that is created, and all subsequent full CRLs that are created.

The internal database stores only the latest CRL and delta CRL. As each new CRL is created, the old one is overwritten.

When you publish CRLs, each update to the CRL and delta CRL is published to the locations specified in the publishing set up. The method of publishing determines how many CRLs are stored. For file publishing, each CRL that is published to a file using the number for the CRL, so no file is overwritten. For LDAP publishing, each CRL that is published replaces the old CRL in the attribute containing the CRL in the directory entry.

Note that by default, CRLs do not contain information about revoked expired certificates. You can enable the server to include revoked expired certificates by selecting that option for the issuing point. If you choose to include expired certificates, information about revoked certificates will not be removed from the CRL when the certificate expires. If you choose not to include expired certificates, information about revoked certificates will be removed from the CRL when the certificate expires.

Setting Up the Issuance of CRLs

The process of setting up the CRL feature includes the following tasks:

  1. The Certificate Manager will use its CA signing key to sign CRLs. If you want to use a separate signing key pair for CRLs, you need to set up a CRL singing key and change the Certificate Manager configuration to allow it to use this key to sign CRLs. See "Getting a CRL Signing Key Pair and Certificate" for details on setting this up.
  2. Setting up CRL Issuing Points by enabling those you want to actually issue CRLs. An issuing point is already set up and enabled for a Master CRL. You can create any additional Issuing Points you want for the CRLs you want to generate from those issuing points. See "Configuring Issuing Points" for complete details.
    3. There are three possible issuing points you can create, select the correct options when configuring the issuing point to define what the CRL will list:
     
    Master CRL. Containing the list of revoked certificates from the entire CA.
     
    ARL. Authority Revocation List containing only revoked CA certificates.
     
    Master CRL and Expired Certificates. Containing the list of revoked certificates from the entire CA that also includes revoked certificates that have expired.
     
  3. Configuring the CRLs for each issuing point by setting the parameters in the Revocation List tab for that issuing point. See "Configuring CRLs for Each Issuing Point" for complete details.
  4. Setting up the CRL extensions if you turned on extensions when you configured the issuing point. See "Setting CRL Extensions" for complete details.
  5. If you want to set up Delta CRLs for a particular issuing point, you need to enable extensions for that issuing point, and enable and configure the DeltaCRLIndicator or CRLNumber.
  6. Setting up the CRLDistributionPoint extension in certificates you issue if you want to include information about the issuing point where CRLs can be found for that certificate. See Chapter 12 "Policies" for information about setting up policies for constraints and certificate extensions; see "CRLDistributionPointsExt" for specifics on setting up the CRLDistributionPoint extension in certificates you issue.
  7. Setting up publishing of CRLs to files, and LDAP directory, or to an OCSP responder. See Chapter 16 "Publishing" for complete details about setting up publishing.

Configuring Issuing Points

You can create Issuing Points that define which certificates are included in new a CRL that is generated. A Master CRL issuing point has already been created for a master CRL containing a list of all revoked certificates for this Certificate Manager.

To create a new Issuing Point:

  1. Log into the CMS console.
  2. Select Certificate Manager, and then CRL Issuing Points.
  3. To delete an issuing point, select that issuing point and click Delete.
    4. To edit an issuing point, select that issuing point and click Edit. You can only change the description for the issuing point, and change the status from enabled to disabled.
     
  4. To add an issuing point, click Add.
    5. The CRL Issuing Point Editor window appears.
     
    You may want to expand this window by dragging at one of the corners, some fields in this window do not appear large enough to read the content.
     
  5. Create the Issuing Point by specifying the following fields:
    6. Enable. Select to enable this Issuing Point; deselect to disable.
     
    CRL Issuing Point name. Provide a name for this issuing point, spaces are not allowed.
     
    Description. Type a description for this Issuing Point.
     
  6. Click OK.
  7. In order to view and configure this issuing point, you need to close the CMS console and log back into it. When you log back in, the new issuing point will appear below the CRL Issuing Points entry in the navigation tree.
    8. All the CRLs you created will appear on the Update Revocation List page of the Agent Services pages.
     
  8. You need to configure this new issuing point, and set up any CRL extensions that will be used in this CRL. See "Configuring CRLs for Each Issuing Point" for details on configuring an issuing point. See "Setting CRL Extensions" for details on setting up the CRL extensions.

Configuring CRLs for Each Issuing Point

You can specify information, such as the generation interval, the CRL version (whether to include CRL extensions), and the signing algorithm the Certificate Manager should use for signing the CRL object for each CRL defined by an issuing point. You need to configure the CRLs for each issuing point you set up.

To configure CRLs for an issuing point:

  1. In the navigation tree, select Certificate Manager, and then select CRL Issuing Points.
  2. Select the Issuing Point by selecting its name below the Issuing Points entry.
  3. Configure the CRL for this issuing point by specifying the fields in the Revocation List tab for that issuing point.
    4. You may want to expand the CMS console window by dragging at one of the corners, some fields in this window do not appear large enough to read the content.
     
    In the Update Frequency section, specify the interval for publishing the CRL to the directory:
     
    Every time a certificate is revoked, or taken off-hold. Select this option if you want the Certificate Manager to generate the CRL every time it revokes a certificate. Keep in mind that the Certificate Manager attempts to publish the CRL to the configured directory whenever it is generated, in this case, every time a certificate is revoked. Publishing a CRL can be time consuming if the CRL is large. Configuring the Certificate Manager to publish CRLs every time a certificate is revoked may engage the server for a considerable amount of time; during this time, the server will not be able to update the directory with any changes it receives.
     
    (This setting is not recommended for a standard installation. You can select this option if you want to see the results of revocation immediately, for example, when testing whether the server publishes the CRL to a flat file.)
     
    Update at this frequency. Select this option if you want the Certificate Manager to generate CRLs at regular intervals. In this case, the server publishes the CRL to the configured directory at the interval you specify.
     
    In the adjoining text field, type the interval, in minutes, at which the Certificate Manager should publish CRLs. For example, if you want the server to publish CRLs every day, you should type 1440 in this field.
     
    with a skew of. If you configure the Certificate Manager to update the CRL at a specific frequency, the server by default adds a 5 second skew to the next update time to allow time to create the CRL and publish it. For example, if you configure the server to update the CRL every 20 minutes, and if the CRL is updated at 16:00:00, the CRL will be updated again at 16:19:55. You can change the skew by editing the default value, which is specified in seconds.
     
    In the CRL Cache section, specify whether to enable CRL caching:
     
    Enable CRL cache. Select to enable the cache. Note, if the cache is disabled, you cannot create delta CRLs. For more information about the cache, see "How CRLs Work".
     
    Cache update interval. Specifies the period of time when the cache is written to file. Set to 0 to have the cache written to file every time a certificate is revoked.
     
    Include expired certificates. Select if you want the server to include revoked certificates that have expired in the CRL. If this is enabled, information about revoked certificates will remain in the CRL after the certificate expires. If you do not enable, information about revoked certificates is removed when the certificate expires.
     
    CA certificates only. Select to include only CA certificates in the CRL; deselect to include all certificates. Selecting this option will create an Authority Revocation List (ARL) listing only revoked CA certificates.
     
    Allow extensions. Select if you want to allow extensions in the CRL. If you enable this option, the server generates and publishes CRLs conforming to X.509 version 2 standard. If you disable this option, the server generates and publishes CRLs conforming to X.509 version 1 standard. By default, the server publishes version 1 CRLs. If you enable this option, be sure to set the required CRL extensions as described in Setting CRL Extensions.
     
    Note: Extensions must be turned on in order to create delta CRLs.
     
    Revocation list signing algorithm. Select the algorithm the server should use to sign the CRL. If the Certificate Manager's signing key type is RSA, select MD2 with RSA, MD5 with RSA, or SHA-1 with RSA. If the Certificate Manager's signing key type is DSA, select SHA-1 with DSA.
     
  4. To save your changes, click Save.
  5. If you selected Allow extensions for this issuing point, you need to configure the extensions for this issuing point. See "Setting CRL Extensions" for details.

Setting CRL Extensions

Complete this step only if you configured the Certificate Manager to create version 2 CRLs in the previous step—that is, if you selected the "Allow extensions" option in when you configured CRLs for each issuing point.

During installation, the Certificate Manager creates default CRL extension rules. Note that the server is configured to add the CRL Reason extension only; all the other rules are in the disabled state. In this step, you modify the default rules to suit your organization's requirements.

To specify the CRL extensions:

  1. In the navigation tree, select Certificate Manager, and then select CRL Issuing Points. Next, select the issuing point in which you want to set extensions and click the plus sign. Next select the CRL Extension entry below the issuing point.
    2. The right pane shows the CRL Extensions Management tab, which lists configured extensions.
     
  2. To modify a rule, select it and then click Edit/View.
  3. Change the information as appropriate.
    4. Be sure to supply all the required values. See "CRL Extension Reference" for complete information about each extension and the parameters for those extensions.
     
  4. Click OK.
    5. You are returned to the CRL Extensions Management tab.
     
  5. To modify other rules, repeat steps 2 through 4.
  6. Click Refresh to see the updated status of all the rules.

CRL Extension Reference

To enable you to issue or publish X.509 v2 CRLs (that is, CRLs with extensions), CMS provides a set of extension rules; each rule enables you to configure the Certificate Manager to set a particular CRL or CRL-entry extension in CRLs it issues.

When deciding whether to add CRL extensions, keep in mind that not all applications support version 2 CRLs. Among the applications that do support extensions, not all applications will recognize every extension. For general guidelines on using these extensions in CRLs, see Appendix G, "Certificate and CRL Extensions."

AuthorityKeyIdentifier

The AuthorityKeyIdentifier rule enables you to configure a Certificate Manager to set the Authority Key Identifier Extension in CRLs. The extension is used to identify the public key that corresponds to the private key used by a CA to sign CRLs.

The PKIX standard recommends that the CA must include this extension in all CRLs it issues. The reason for this is that in certain situations, a CA's public key may change (for example, when the key gets updated) or the CA may have multiple signing keys (either because of multiple concurrent key pairs or because of key changeover). In these cases, the CA ends up with more than one key pair. When verifying a signature on a certificate, other applications need to know which key was used in the signature.

For general information about the authority key identifier extension in CRLs, see authorityKeyIdentifier.


Table 15-1    AuthorityKeyIdentifierExt Configuration Parameters  


Parameter

Description

enable

 

Specifies whether the rule is enabled or disabled. Select to enable, deselect to disable (default).

 

critical

 

Select if you want the server to mark the extension critical; deselect if you want the server to mark the extension noncritical (default).

 


CRLNumber

The CRLNumber rule enables you to configure a Certificate Manager to set the CRL Number Extension in CRLs. This extension specifies a monotonically increasing sequence number for each CRL issued by a CA, allowing CRL users to easily determine when a particular CRL supersedes another CRL.

For general guidelines on setting the CRL number extension in CRLs, see CRLNumber.


Table 15-2    CRLNumber Configuration Parameters  


Parameter

Description

enable

 

Specifies whether the rule is enabled or disabled. Select to enable (default), deselect to disable.

 

critical

 

Select if you want the server to mark the extension critical; deselect if you want the server to mark the extension noncritical (default).

 


CRLReason

The CRLReason rule enables you to configure a Certificate Manager to set the CRL ReasonCode Extension in CRL entries. The extension is used to identify the reason for the revocation of a certificate included in the CRL.

For general guidelines on setting the CRL reason code in CRL entries, see reasonCode.

For a list of reason codes, see "Reasons for Revoking a Certificate".


Table 15-3    CRLReason Configuration Parameters  


Parameter

Description

enable

 

Specifies whether the rule is enabled or disabled. Select to enable (default), deselect to disable.

 

critical

 

Select if you want the server to mark the extension critical; deselect if you want the server to mark the extension noncritical (default).

 


DeltaCRLIndicator

The DeltaCRL rule enables you to configure a Certificate Manager to set the CRL DeltaCRLIndicator Extension in CRLs. The extension is included in generated deltas, which constitutes them and provides reference to the base CRL. Enabling this extension also enables the generation of delta CRLs for this issuing point.


Table 15-4    DeltaCRL Configuration Parameters  


Parameter

Description

enable

 

Specifies whether the rule is enabled or disabled. Select to enable, deselect to disable (default).

 

critical

 

Select if you want the server to mark the extension critical (default); deselect if you want the server to mark the extension noncritical.

 


FreshestCRL

The FreshestCRL rule enables you to configure a Certificate Manager to set the FreshestCRL Extension in CRLs. This extension is placed in the full CRL to indicate where to find latest delta CRL.


Table 15-5    FreshestCRL Configuration Parameters  


Parameter

Description

enable

 

Specifies whether the rule is enabled or disabled. Select to enable, deselect to disable (default).

 

critical

 

Select if you want the server to mark the extension critical; deselect if you want the server to mark the extension noncritical (default).

 

numPoints

 

Indicates the number of issuing points for delta CRL. Can be set to 0 or any positive integer, the default is 0.

Note: When you set this to an integer other than 0, you need to set this and then click OK to close this window. You then edit this rule again and the fields to set these points will be present in the interface.

 

pointType<n>

 

Specifies the type of issuing point for the <n> issuing point. For each number specified in numPoints, there will be an equivalent number of numbered pointType parameters.

Select DirectoryName or URI.

 

pointName<n>

 
  • If pointType is set to directoryName, the value must be a string in the form of X.500 name, similar to the subject name in a certificate. For example, CN=CACentral,OU=Research Dept,O=Example Corporation,C=US.
  • If pointType is set to URI, the name must be a URI; the URI must be an absolute pathname and must specify the host. For example:

http://testCA.example.com/get/your/crls/here/

 


HoldInstruction

The HoldInstruction rule enables you to configure a Certificate Manager to set the CRL Hold Instruction Extension in CRL entries. The extension is a non-critical CRL entry extension that is used to specify a registered instruction identifier—the identifier indicates what action the validating application should take when it encounters a certificate that has been placed on hold.

For general guidelines on setting the CRL hold instruction code in CRL entries, see holdInstructionCode.


Table 15-6    HoldInstruction Configuration Parameters  


Parameter

Description

enable

 

Specifies whether the rule is enabled or disabled. Select to enable, deselect to disable (default).

 

critical

 

Select if you want the server to mark the extension critical; deselect if you want the server to mark the extension noncritical (default).

 

instruction

 

Specifies the action a validating application must take when it encounters a certificate that has been put on hold.

Permissible values: none, callissuer, or reject.

  • none specifies that the validating application need not do anything; the PKIX standard says that this is semantically equivalent to the absence of a holdInstructionCode (default).
  • callissuer specifies that the validating application must call the CA that has issued the certificate or reject the certificate.
  • reject specifies that the validating application must reject the certificate on hold.
 


InvalidityDate

The InvalidityDate rule enables you to configure a Certificate Manager to set the Invalidity Date Extension in CRL entries. The extension is a non-critical CRL entry extension that is used to specify the date on which it is known or suspected that the private key was compromised or that the certificate otherwise became invalid.

For general guidelines on setting the invalidity date extension in CRL entries, see invalidityDate.


Table 15-7    InvalidityDate Configuration Parameters  


Parameter

Description

enable

 

Specifies whether the rule is enabled or disabled. Select to enable (default), deselect to disable.

 

critical

 

Select if you want the server to mark the extension critical; deselect if you want the server to mark the extension noncritical (default).

 


IssuerAlternativeName

The IssuerAlternativeName rule enables you to configure a Certificate Manager to set the Issuer Alternative Name Extension in CRLs. This extension enables binding of or associating alternative identities, such as a mail address, a DNS name, an IP address, and a uniform resource indicator (URI), with the issuer of the CRL.

For general guidelines on setting the issuer alternative name extension in CRLs, see issuerAltName.


Table 15-8    IssuerAlternativeName Configuration Parameters 


Parameter

Description

enable

 

Specifies whether the rule is enabled or disabled. Select to enable, deselect to disable (disable).

 

critical

 

Select you want the server to mark the extension critical; deselect if you want the server to mark the extension noncritical (default).

 

numNames

 

Specifies the total number of alternative names or identities permitted in the extension. Note that each name has a set of configuration parameters— nameType and name—and you must specify appropriate values for each of those parameters; otherwise, the policy rule will return an error.

You can change the total number of identities by changing the value specified in this field; there's no restriction on the total number of identities you can include in the extension. Each set of configuration parameters is distinguished by <n>, which is an integer derived from the value you assign in this field. For example, if you set the numNames parameter to 2, <n> would be 0 and 1.

 

nameType<n>

 

Specifies the general-name type. Select from the following:

  • Select rfc822Name if the name is an Internet mail address.
  • Select directoryName if the name is an X.500 directory name.
  • Select dNSName if the name is a DNS name.
  • Select ediPartyName if the name is a EDI party name.
  • Select URL if the name is a uniform resource identifier (default).
  • Select iPAddress if the name is an IP address.
  • Select OID if the name is an object identifier.
  • Select otherName if the name is in any other name form.
 

name<n>

 

Specifies the general-name value.

Permissible values: Depends on the name type specified in the nameType<n> field.

  • If the type is rfc822Name, the value must be a valid Internet mail address in the local-part@domain format.
 

 

 
  • If the type is directoryName, the value must be a string form of X.500 name, similar to the subject name in a certificate. For example, CN=CACentral,OU=Research Dept,O=Example Corporation,C=US.
 

 

 
  • If the type is dNSName, the value must be a valid domain name in the DNS format. For example, testCA.example.com.
 

 

 
  • If the type is ediPartyName, the name must be an IA5String. For example, Example Corporation.
 

 

 
  • If the type is URL, the value must be a non-relative universal resource identifier (URI). For example: http://testCA.example.com.
 

 

 
  • If the type is iPAddress, the value must be a valid IP address specified in dot-separated numeric component notation. It can be the IP address or the IP address including the netmask.
 

 

 
  • If the type is OID, the value must be a unique, valid OID specified in the dot-separated numeric component notation. Although you can invent your own OIDs for the purposes of evaluating and testing this server, in a production environment, you should comply with the ISO rules for defining OIDs and for registering subtrees of IDs. See Appendix H "Object Identifiers" for information on allocating private OIDs. For example, 1.2.3.4.55.6.5.99.
 

 

 
  • If the type is otherName, the name must be must be the absolute path to the file that contains the general name in its base-64 encoded format. For example, /usr/netscape/servers/extn/ian/othername.txt.
 


IssuingDistributionPoint

The IssuingDistributionPoint rule enables you to configure a Certificate Manager to set the Issuing Distribution Point Extension in CRLs. The CRL issuing point extension enables you to specify a pointer to a particular CRL and to include additional information about the CRL at that location—whether it covers revocation of end-entity certificates only, CA certificates only, or revoked certificates that have a limited set of reason codes.

Optionally, each issuing point may contain a set of reason flags, indicating what revocation reasons are covered by the CRL at the specified location. Note that you can modify the rule to support any name form by making the appropriate changes to the sample code provided for this purpose, see the CMS SDK.

For general guidelines on setting the issuing distribution point extension in CRLs, see issuingDistributionPoint.


Table 15-9    IssuingDistributionPoint Configuration Parameters 


Parameter

Description

enable

 

Specifies whether the rule is enabled or disabled. Select to enable, deselect to disable (default).

 

critical

 

Select you want the server to mark the extension critical (default); deselect if you want the server to mark the extension noncritical.

 

pointType

 

Specifies the type of the issuing distribution point from the following

  • DirectoryName specifies that the type is an X.500 Directory Name.
 

 
  • URI specifies that the type is a uniform resource indicator.
 

pointName

 

Specifies the name of the issuing distribution point. The name of the distribution point depends on the value specified for the pointType parameter.

  • If the pointType attribute is set to DirectoryName, the name must be an X.500 Name. For example:

CN=CRLCentral,OU=Research Dept,O=Example Corporation,C=US

 

 
  • If the pointType attribute is set to URI, the name must be a URI; the URI must be an absolute pathname and must specify the host. For example:

http://testCA.example.com/get/your/crls/here/

(Note that the CRL may be stored in the directory entry corresponding to the CRL issuing point, which may be different than the directory entry of the CA.)

 

onlySomeReasons

 

Specifies the reason codes associated with the distribution point.

Permissible values: A combination of reason codes—unspecified, keyCompromise, cACompromise, affiliationChanged, superseded, cessationOfOperation, certificateHold, and removeFromCRL—separated by commas. Leave field blank if the distribution point contains revoked certificates with all reason codes or if you don't want to set this field (default).

 

onlyContainsCACerts

 

Select if the distribution point contains CA certificates only; deselect if the distribution point contains all types of revoked certificates (default).

 

onlyContainsUserCerts

 

Select if the distribution point contains user certificates only; deselect if the distribution point contains all types of certificates (default).

 

indirectCRL

 

Select if the distribution point contains an indirect CRL; deselect if the distribution point doesn't contain an indirect CRL (default).

 




Previous      Contents      Index      DocHome      Next     

© 2001 Sun Microsystems, Inc. Portions copyright 1999, 2002-2004 Netscape Communications Corporation. All rights reserved.


Last Updated November 23, 2004