| Administrator's Guide Red Hat Certificate System |
| Previous |
Contents |
Index |
Next |
Chapter 15
Revocation and CRLs
Red Hat Certificate System (CS) 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.
- An end user can revoke only those certificates that contain the same subject name as in the certificate presented for authentication; if using a challenge password, the user can revoke only the certificate that is associated with that password. After successful authentication, the server lists the certificates belonging to the end user. The end user can then select the certificate to be revoked or can revoke all certificates in the list. The end user can also specify additional details, such as the date of revocation and revocation reason for each certificate or for the list as a whole. For instructions on how end users revoke their certificates, see the online help available by clicking the Help buttons in the end-entity forms.
- Agents can revoke certificates based on a range of serial numbers or based on one or more subject name components. Upon submission of the revocation request, agents receive a list of certificates from which they can pick the ones to be revoked. For instructions on how agents revoke end-entity certificates, see the CS Agent's Guide.
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:
- ChallengeRevoke1.html (the form that allows challenge password based revocation of client or personal certificates)
- UserRevocation.html (the form that allows SSL client authenticated revocation of client or personal certificates)
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 CS 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 (page 115) 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:
- Set up an instance of the CMCAuth Authentication plug-in module. An instance is enabled and configured by default. See "Setting Up CMC Enrollment," on page 385 for details on setting up this plug-in.
- Use your agent certificate to sign revocation requests. See "CMC Revoke Utility," on page 572 for information on signing requests.
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 CS and is available from the following directory:
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>
Note: Surround values that include spaces in quotation marks.
Testing CMC Revoke
.\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 .redhat, the nickname of the certificate is RegistartionManagerAgentCert, and the serial number of the certificate is 22, the command would look like this:
.\CMCRevoke -d".\.redhat" -n"RegistartionManagerAgentCert" -i"cn=agentAuthMgr" -s22 -m0 -c"test comment"
- Select the Revocation Tab.
- Select the CMC Revoke link on the menu.
- Paste the output of step 2 into the text area
Remove "-----BEGIN NEW CERTIFICATE REQUEST-----" and "----END NEW CERTIFICATE REQUEST-----" from the pasted content.
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:
- Revoke the certificate if any of the certificate assertions becomes false.
- Make the revoked certificate status available to parties or applications that need to verify its validity status.
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," on page 582" 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," on page 104 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 Red Hat Servers
Because Red Hat 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 CS 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:
- 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," on page 104 for details on setting this up.
- 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," on page 579 for complete details.
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 and Expired Certificates. Containing the list of revoked certificates from the entire CA that also includes revoked certificates that have expired.
- 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," on page 580 for complete details.
- Setting up the CRL extensions if you turned on extensions when you configured the issuing point. See "Setting CRL Extensions," on page 582 for complete details.
- 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.
- 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," on page 501 for specifics on setting up the CRLDistributionPoint extension in certificates you issue.
- 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:
- Log into the CS console.
- Select Certificate Manager, and then CRL Issuing Points.
- To delete an issuing point, select that issuing point and click Delete.
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.
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.
- Click OK.
- In order to view and configure this issuing point, you need to close the CS 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.
All the CRLs you created will appear on the Update Revocation List page of the Agent Services pages.
- 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," on page 580 for details on configuring an issuing point. See "Setting CRL Extensions," on page 582 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:
- In the navigation tree, select Certificate Manager, and then select CRL Issuing Points.
- Select the Issuing Point by selecting its name below the Issuing Points entry.
- Configure the CRL for this issuing point by specifying the fields in the Revocation List tab for that issuing point.
You may want to expand the CS console window by dragging at one of the corners, some fields in this window do not appear large enough to read the content.
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.
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," on page 577.
- 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" on page 582.
- 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.
- To save your changes, click Save.
- If you selected Allow extensions for this issuing point, you need to configure the extensions for this issuing point. See "Setting CRL Extensions," on page 582 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:
- 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.
Be sure to supply all the required values. See "CRL Extension Reference," on page 583 for complete information about each extension and the parameters for those extensions.
- To modify other rules, repeat steps 2 through 4.
- 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), CS 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" on page 744.
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" on page 745.
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" on page 747.
For a list of reason codes, see "Reasons for Revoking a Certificate," on page 575.
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.
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.
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" on page 747.
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" on page 747.
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" on page 746.
Table 15-8 IssuerAlternativeName Configuration Parameters
- 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.
- 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.
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 CS SDK.
For general guidelines on setting the issuing distribution point extension in CRLs, see "issuingDistributionPoint" on page 746.
| Previous |
Contents |
Index |
Next |