Previous Contents Index Next |
iPlanet Certificate Management System Customization Guide |
Chapter 3 End-Entity Interface Reference
This chapter provides a detailed reference of all the service interfaces available on an end-entity port of iPlanet Certificate Management Server. For each interface, there is a description including the URI used and the purpose, a list of forms that use the interface by default, a detailed description of valid input parameters and their values, and information about the response which lists the templates used and the additional JavaScript variables available.
The chapter has the following sections:
Overview of End-Entity Interfaces
Certificate Enrollment Protocol Interface
Challenge Revocation Interface
Display Certificate By Serial Number Interface
Display Certificate From Request Interface
Get Certificate By Serial Number Interface
Overview of End-Entity Interfaces
The following table lists the end-entity interfaces and their functions. The sections that follow cover each interface in detail.
Certificate Enrollment Protocol Interface
Description
URI: /cgi-bin/pkiclient.exe
Available on: Certificate Manager and Registration Manager
Function: Handles Certificate Enrollment Protocol (CEP) requests from devices such as Virtual Private Network (VPN) routers.
VPN routers use CEP to enroll in and get information about their PKI. The Certificate Enrollment Protocol interface uses CEP to issue new certificates, distribute Certificate Revocation List (CRL) data, and distribute the CA certificate.
Default Forms
There are no forms that use the Certificate Enrollment Protocol. The interface is provided so that VPN clients, such as routers, can use CEP to interact with the PKI.
Request Parameters
You will not generally develop your own request forms or response templates for use with CEP. The Certificate Enrollment Protocol interface complies with the CEP protocol developed by Cisco, so if your application or device uses this protocol it will be able to use the Certificate Enrollment Protocol Interface.
To use the interface with a Cisco router, for example, you configure the router to point to the end-entity gateway port using the router's enrollment url command. You can then use crypto ca enroll to request a certificate:
> enrollment url https://example:443/
The router uses the CEP protocol and expects to find the /cgi-bin/pkiclient.exe interface at the URL named by the enrollment url command. The details of interacting with the interface are handled by the protocol itself.
Challenge Revocation Interface
Description
URI: /challenge_revocation1
Available on: Certificate Manager and Registration Manager
Function: Allows an entity to revoke a certificate using a challenge password set during enrollment.
The Challenge Revocation interface is useful if an entity must revoke a certificate that is not available or not valid for SSL client authentication. (The Revocation Interface can be used to present a certificate using SSL client authentication for revocation.) To use this interface, the challenge password for revocation must be set during enrollment (see the challengePassword request parameter in Enrollment Interface).
Default Forms
The ChallengeRevoke1.html form is the only default form that uses the Challenge Revocation interface. It allows an end user to enter either the certificate's serial number or subject name and the challenge password to revoke the certificate.
Request Parameters
The following table lists the parameters accepted by the Challenge Revocation interface.
Response
The response from the Challenge Revocation interface will be identical to a response from the Revocation interface. See the Response section in Revocation Interface for details on what JavaScript variables are returned in the response template.
Display Certificate By Serial Number Interface
Description
URI: /displayBySerial
Available on: Certificate Manager
Function: Displays a single certificate in human-readable form.
The Display Certificate By Serial Number interface is typically used within a form that lists certificates to display detailed information about a selected certificate. The response is an HTML page built from a template (not just raw certificate data), so this interface should not be used to retrieve certificates for processing (such as importing into a browser); use the Get Certificate By Serial Number Interface (/getBySerial) instead.
Default Forms
The Display Certificate By Serial Number interface is used in the queryCert.template file. Each certificate in the list of certificates satisfying the query has a button the user can press to see the certificate in detail. This button submits data to the Display Certificate By Serial Number interface.
Request Parameters
The following table lists the parameters accepted by the Display Certificate By Serial Number interface.
Response
The default response template is displayBySerial.template. The base JavaScript for responses is inserted in place of the <CMS_TEMPLATE> tag. In addition, the Display Certificate By Serial Number interface adds the JavaScript variables listed in the following table:
Display Certificate From Request Interface
Description
URI: /displayCertFromRequest
Available on: Certificate Manager or Registration Manager
Function: Retrieves the certificate associated with an enrollment or renewal request to be displayed in a response template.
The Display Certificate From Request interface is typically used in JavaScript embedded in the response template of an enrollment or renewal request. This interface uses the requestID returned in the JavaScript of a response to fetch the associated certificate.
In the requestStatus.template file, there is JavaScript code to build a URL that fetches the certificate from the Display Certificate From Request Interface if the CMS server is a Registration Authority.
The requestID parameter from the response template is required: it identifies the request from which to extract the certificate.
Default Forms
By default, the Display Certificate From Request interface is used by the requestStatus.template file only.
Request Parameters
The following table lists the parameters accepted by the Display Certificate From Request interface.
Response
By default, the displayCertFromRequest.template file is used to create the response. The <CMS_TEMPLATE> tag is replaced with the the base JavaScript for responses. In addition, the Get Certificate From Request interface adds the JavaScript variables listed in the following table:
Available on: Certificate Manager and Registration Manager.
Function: Enrolls an entity into the Public-Key Infrastructure (PKI).
This servlet uses data from an HTTP POST or HTTP GET to formulate a certificate request, hands the request off to a Certificate Manager, and returns a response (which may include the newly issued certificate) to the entity.
The certificate request may be based only on the data in the request, or it may get additional data from an authentication plug-in named in the authenticator parameter. If an authentication plug-in is used, the Certificate Manager may be able to automatically issue a certificate which is passed to the entity in the enrollment servlet's response. If no authentication plug-in is used, the request is placed in an agent queue for manual approval and the enrollment servlet returns a "request pending" page to the entity.
Default Forms
There are two types of default HTML forms that use the enrollment interface: manual or automated enrollment. Forms that use automated enrollment send an authentication plug-in name as a parameter in the request which the servlet can use to authenticate and process the request without manual intervention.
The default manual enrollment forms are:
ManUserEnroll.html for requesting client certificates.
ManServerEnroll.html for requesting server certificates.
ManObjSign.html for requesting object signing certificates.
ManCAEnroll.html for requesting subordinate Certificate Manager signing certificates.
ManRAEnroll.html for requesting Registration Manager certificates. The default automated enrollment forms are:
DirUserEnroll.html uses a UserDirEnrollment instance of the UidPwdDirAuth plug-in class by default.
DirPinUserEnroll.html uses a PinDirEnrollment instance of the UidPwdPinDirAuth plug-in class by default.
Request Parameters
The following table lists the parameters accepted by the enrollment interface.
Table 3-7    Parameters Accepted by the Enrollment Interface
Parameter
Format and Description
Distinguished Name (DN) string. See RFC 2253.
DN to be used for the certificate subject.
Example: CN=Alice Apple, UID=alice, OU=People, O=Example, C=US
Name of the entity making a request; helps identify the requestor during manual enrollment.
Example: Alice Apple
Email address of the entity making a request. May be used to send out notification when a certificate has been issued.
Example: alice@example.com
Additional comments provided by the requestor on the HTML form. This field can be used if there is additional information you want to collect to help the manual enrollment.
Parameters for setting bits in the netscape-cert-type certificate extension. See http://home.netscape.com/eng/security/comm4-cert-exts.html for details. A true value sets the bit to 1; false sets the bit to 0.
Parameters for setting bits in the keyUsage certificate extension. A true value sets the bit to 1; false sets the bit to 0.
Sets the keyUsage extension bit (6) indicating that the key may be used to sign Certificate Revocation Lists (CRLs).
Sets the keyUsage extension bit (3) indicating that the key may be used to encipher application data (as opposed to key material).
Sets the keyUsage extension bit (8) indicating that the key may only be used to decipher data and keys. If this parameter is true, keyAgreement should also be true.
Sets the keyUsage extension bit (0) indicating that the key may be used to sign any data. This parameter should be true for SSL client certificates, S/MIME signing certificates, and object signing certificates.
Sets the keyUsage extension bit (7) indicating that the key may only be used to encipher data and keys. If this parameter is true, keyAgreement should also be true.
Sets the keyUsage extension bit (4) indicating that the key may be used to encipher and decipher keys during key agreement.
Sets the keyUsage extension bit (5) indicating that the key may be used to sign other certificates. All CA signing certificates should set this parameter to true.
Sets the keyUsage extension bit (2) indicating that the key may be used to encipher symmetric session keys. This parameter should be true for SSL server and S/MIME encryption certificates.
Sets the keyUsage extension bit (1) indicating that the key may be used to create non-repudiable (by the signer) digital signatures. Non-repudiation service requires more infrastructure, planning, and policy than just setting this bit. Consider the ramifications before using this bit
Parameters to configure automatic authentication for entity requests.
Specifies the name of the authentication plug-in instance to use to authenticate the entity.
Specifies a unique identifier passed to the authentication plug-in.
An optional identifying string that helps to authenticate an entity. Usually used when the Pin Generator tool has been used to populate a directory with unique identifiers for each user.
Specifies the password passed to the authentication plug-in.
Specifies the nickname that should be associated with the certificate in the reply; used with Certificate Request Management Format (CRMF) requests.
ca | CEP-Request | client | objSignClient | ra | server | other
Specifies the type of certificate requested by the entity. The default is client. The certType is not associated with any certificate extensions. It may be used by policy modules to make decisions, and it may be used by a CMS server to determine how to decode the request or format the response.
An optional challenge phrase or password that can be used later by the entity to revoke the certificate. This parameter is optional. If you use this, entities can use the "Challenge Revocation Interface" (/challenge_revocation1)with this challenge password to revoke a certificate without manual intervention and without SSL client authentication.
If requestFormat = crmf, this parameter should be used to send the base-64 encoded CRMF request.
Used only when importCert = true. The default, if this parameter is not explicitly passed, is true. If set to true, a successful certificate request will return a PKCS #7 formatted certificate chain; if set to false, a single, DER-encoded certificate will be returned. The certificate chain includes the issued certificate and the CA (issuer) certificate.
If true, and the certificate request is not deferred or rejected, the CMS server's response will be binary data with the MIME type determined by the importCertMimeType parameter. The data returned will be either a certificate or a certificate chain, based on the value of importCAChain.
Sets the MIME type the CMS server uses when a certificate is returned to the requestor. The default is application/x-x509-user-cert. The MIME type should be in the standard MIME type format of <type>/<subtype>.
If requestFormat = pkcs10, this parameter should be used to send the base-64 encoded certificate request.
clientAuth | crmf | keygen | pkcs10
The value indicates the format used to submit the certificate request:
clientAuth - information for the new request is taken from the certificate presented by the client during SSL client authentication.
crmf - the certificate request is a base-64 encoded blob contained in the CRMFRequest parameter.
keygen - the certificate request is a base-64 encoded blob generated using the HTML <KEYGEN> tag. It is contained in the subjectKeyGenInfo parameter.
pkcs10 - the certificate request is a base-64 encoded blob contained in the pkcs10Request parameter.
If requestFormat=keygen, this parameter should be used to send the base-64 encoded keygen request. To use the <KEYGEN> HTML tag to cause the browser to generate the request using this parameter, the format is
Filename relative to the template directory (web/ee, web/agent/ca, web/agent/kra, or web/agent/ra) of a file to use as the response template. This template will be used for any response, overriding default template settings.
Response
The Registration Authority or Certificate Authority that process an enrollment request will perform some processing, determine the status of the request, then return a result using the appropriate template for the status.
The response templates are ASCII files that you can edit to create responses suited to your needs. The templates may include JavaScript that depends on the JavaScript inserted in place of the <CMS_TEMPLATE> tag when the response is sent. The status of the request determines which template will be used for the response. The following table describes the templates used by the enrollment interface (more details on the request status codes can be found in Table 3-9):
The <CMS_TEMPLATE> tag in the selected template is replaced with the base JavaScript code. In addition, the Enrollment interface may add the JavaScript variables listed in the following table. Not all templates use all of the variables listed in the table; a variable is only included when it is used (for example, the EnrollmentSuccess.template does not include result.fixed.unexpectedError).
Table 3-9    Variables Returned by the Enrollment Interface
Variable
Description
ca | CEP-Request | client | objSignClient | ra | server | other
The type of certificate returned. This value is the same as the certType value passed to the interface in the request.
A message providing more details about the error described in errorDetails. This variable is only present if an error occurred while processing the request.
A message explaining the error that occurred while processing the enrollment request. This variable is only present if an error occurred while processing the request.
The fully qualified domain name of the CMS server that processed the request. This allows the resulting template to construct forms that post data to the same interface using the same port.
A unique number assigned by the CMS server to this request. This is especially useful for pending requests since there is no unique certificate serial number yet assigned.
A code indicating the current status of the request:
1 (Unauthorized): The request specified a value for an authenticator to perform an automated enrollment, and the authenticator did not authorize the request.
2 (Success): Processing the request was successful and a certificate has been issued. If importCert was set to true, the response will include code (from the EnrollSuccess.template) to import the certificate into the browser making the request. Otherwise, the response is only a success message.
3 (Pending): The request has been successfully processed by the CMS server and added to a queue for approval by an agent. If the request has been submitted to another Certificate Manager or Data Recovery Manager and is currently pending in the queue for that service, the response template will be GenSvcPending.template instead of GenPending.template.
4 (Reserved): Not currently used.
5 (Rejected): The request was rejected during policy processing.
6 (Error): An error occurred when the CMS server processed the request. The error may be the result of missing or improperly formatted parameters.
7 (Exception): An unknown or unexpected error occurred when the CMS server processed the request.
The protocol that was used to make the request. Use this along with host and port to make sure any new requests to the end-entity port use the correct scheme.
A message explaining the exception or unexpected error that occurred.
Variables added to each record object. Each record object is added as an element of the recordSet array. Multiple records may be returned if more than one certificate was generated as a result of the request. Dual-key requests (for example, if the request parameter requestFormat = crmf) may return two certificates if the request is successfully processed and approved.
The newly issued certificate in base-64 encoded format. This string includes the "-----BEGIN CERTIFICATE-----" header and "-----END CERTIFICATE-----" footer.
A string of hexadecimal numbers separated by colons that represent the certificate fingerprints. There are three substrings: one each for the MD2, MD5, and SHA1 fingerprint. Each fingerprint begins with the hash algorithm name and a colon, and ends with a newline (\n).
A long text string that shows all of the certificate data in a human readable form.
If the request was rejected by policy processing on the CMS server, this variable will contain a message explaining why.
The serial number (in decimal) of the newly issued certificate.
Available on: Certificate Manager only.
Function: Retrieves the CA certificate or certificate chain for the Certificate Manager either in binary form for use by an application or in a format for display.
The Get CA Chain interface accepts an operation (for example, download) and a MIME type to be used for the response. The response is always the CA certificate or certificate chain (if the CA certificate is not self-signed) for the Certificate Manager handling the request. No templates are used; the response is either ASCII data that can be displayed or a binary blob (using the indicated MIME type) that can be used by the requesting application.
Using the Get CA Chain interface to display certificates is useful for creating data that can be imported into another application such as an HTTP or LDAP server.
Default Forms
The Get CA Chain interface uses one default form: GetCAChain.html. This form allows an entity to choose one of four operations:
Import the CA certificate chain into a browser (download).
Download the CA certificate chain in binary form (downloadBIN).
Display the CA certificate chain in PKCS #7 for importing into a server (display).
Display certificates in the CA certificate chain for importing individually into a server (displayIND).
Request Parameters
The following table lists the parameters accepted by the Get CA Chain interface.
Response
The Get CA Chain interface does not use any templates. The response is just the requested certificate or certificates in the format indicated by the request parameters.
Get Certificate By Serial Number Interface
Available on: Certificate Manager only
Function: Retrieves the certificate with the given serial number in a specified format. The certificate can be imported into a browser.
This interface is used in the EnrollSuccess.template and RenewalSuccess.template to download and import the newly issued certificate. The displayBySerial.template also uses this interface to create "Import Certificate" and "Import S/MIME Certificate" buttons on a page that displays a certificate; this allows a user to retrieve and import a certificate that was issued manually.
Default Forms
There are no default forms that use the Get Certificate By Serial Number interface. This interface is usually used embedded in a response template to either embed a certificate in the response or provide a button on a form that downloads and imports the certificate.
Request Parameters
The following table lists the parameters accepted by the Get Certificate By Serial Number interface.
Response
If importCert = true in the request, the response is a binary blob containing the certificate and no templates are used to construct the response. See the Request Parameters for details on how the response is formatted.
By default, the ImportCert.template file is used to create the response. The <CMS_TEMPLATE> tag is replaced with the base JavaScript for responses. In addition, the Get Certificate By Serial Number interface adds the JavaScript variables listed in the following table:
Table 3-12    Variables Returned by the Get Certificate By Serial Number Interface
Variable
Description
The nickname for the certificate. By default, this is just the certificate subject DN.
ca | CEP-Request | client | objSignClient | ra | server | other
The type of certificate returned. This value is the same as the certType value passed to the interface in the request.
The CMMF response data containing the certificate (if cmmfResponse was true in the request). If the browser supports the Personal Security Manager crypto API, you can use this response with a call to importUserCertificates to import the certificate into a local database:
importUserCertificates(result.fixed.nickname,
result.fixed.cmmfResponse, true);
(The last parameter indicates whether the user should be prompted to back up the key.)
A message providing more details about the error described in errorDetails. This variable is only present if an error occurred while processing the request.
A message explaining the error that occurred while processing the enrollment request. This variable is only present if an error occurred while processing the request.
The fully qualified domain name of the CMS server that processed the request. This allows the resulting template to construct forms that post data to the same interface using the same port.
The protocol that was used to make the request. Use this along with host and port to make sure any new requests to the end-entity port use the correct scheme.
Variables added to each record object. Each record object is added as an element of the recordSet array. Multiple records may be returned if more than one certificate was generated as a result of the request. Dual-key requests (for example, if the request parameter requestFormat = crmf) may return two certificates if the request is successfully processed and approved.
The newly issued certificate in base-64 encoded format. This string includes the "-----BEGIN CERTIFICATE-----" header and "-----END CERTIFICATE-----" footer.
A string of hexadecimal numbers separated by colons that represent the certificate fingerprints. There are three substrings: one each for the MD2, MD5, and SHA1 fingerprint. Each fingerprint begins with the hash algorithm name and a colon, and ends with a newline (\n).
A long text string that shows all of the certificate data in a human readable form.
Get Certificate From Request Interface
Description
URI: /getCertFromRequest
Available on: Certificate Manager or Registration Manager
Function: Retrieves the certificate associated with an enrollment or renewal request to be displayed in a response template or imported into a browser.
The Get Certificate From Request interface is typically used in JavaScript embedded in the response template of an enrollment or renewal request. This interface uses the requestID returned in the JavaScript of a response to fetch the associated certificate.
In the EnrollSuccess.template and RenewalSuccess.template files, there is JavaScript code to build a URL that fetches the certificate from the Get Certificate From Request interface. The URL is assigned to the window.location object, which causes the contents of the URL to be displayed in-line in the response.
The requestID parameter from the response template is required: it identifies the request from which to extract the certificate. A parameter can also be used to instruct the requesting browser to import the certificate into its database: importCert or cmmfResponse (for browsers that support CMMF).
Default Forms
The Get Certificate From Request interface is used by response templates, not forms that an entity submits. The interface is used in these templates to incorporate the certificate in the page itself, so that it can be displayed and possibly imported into the browser. The templates that use the interface by default are:
displayCertFromRequest.template is a generic template that shows how to display a certificate from a request.
EnrollSuccess.template is the template returned by a successful enrollment request (when a certificate has been issued, not when the request is successful but still pending).
RenewalSuccess.template is the template returned by a successful automated renewal request (such as a renewal using SSL client authentication).
Request Parameters
The following table lists the parameters accepted by the Get Certificate From Request interface.
Response
If importCert = true in the request, the response is a binary blob containing the certificate and no templates are used to construct the response. See the Request Parameters for details on how the response is formatted.
By default, the ImportCert.template file is used to create the response. The <CMS_TEMPLATE> tag is replaced with the base JavaScript for responses. In addition, the Get Certificate From Request interface adds the JavaScript variables listed in the following table:
Available on: Certificate Manager only
Function: Retrieves the current Certificate Revocation List (CRL) for this certificate authority.
This interface can be used to retrieve a CRL for display or importing into an application and it can be used simply to check whether a certificate appears on the current CRL.
Default Forms
The only default form that uses the Get CRL interface is DisplayCRL.html. This form allows the user to choose any of the possible options for the getCRL interface:
Check whether a particular certificate is on the CRL.
Import the CRL into a browser.
Request Parameters
The following table lists the parameters accepted by the Get CRL interface.
Response
Responses to requests for checkCRL or displayCRL use the displayCRL.template template. The <CMS_TEMPLATE> tag is replaced with the base JavaScript for responses. In addition, the Get CRL interface adds the JavaScript variables listed in the following table:
Available on: Certificate Manager
Function: Retrieves a list of certificates that match a query filter.
The query criteria are search filters that the interface uses to select certificates in the Certificate Manager's repository. The queryCert.html default form contains JavaScript code that can construct all possible filters. You should study this file for examples before you write code to construct your own forms. Valid query filter constructions are explained in the Request Parameters section.
The response is constructed using the queryCert.template. The listing that this template provides by default has code for displaying a listed certificate in more detail, revoking a listed certificate, or revoking all certificates listed.
Default Forms
The List Certificates interface uses two default forms:
queryBySerial.html is a simple form that accepts a lower and upper bound for the range of serial numbers and the option to skip revoked or invalid certificates. This form constructs a simple query filter to select certificates that meet the user's preferences for certificate status (valid, invalid, and revoked).
queryCert.html is a complex form that allows the user to specify all possible query criteria. This form makes extensive use of JavaScript to formulate a query filter for any criteria the user chooses.
Request Parameters
The following table lists the parameters accepted by the List Certificates interface.
The queryCertFilter parameter must be a valid query filter. The syntax and valid query parameters are too complex to describe in the parameter table. Details about valid parameters and values for query filters are in a separate table following the parameters.
The following table describes the parameter names that are valid for constructing query filters, and the range of valid values that can be used with the parameter. The parameters can be combined using parentheses and logical operators (as described in the previous table) to construct query filters of arbitrary complexity.
In a filter, the parameter name is compared to the expression value using one of the relational operators = (matches), < (less than), <= (less than or equal to), > (greater than), or >= (greater than or equal to). Some expressions (such as x509cert.subject) accept the asterisk (*) as a wildcard to match 0 or more characters; for example. "E=jdoe*" matches "E=jdoe@example.com" and "E=jdoe@example.com."
Table 3-18    List Certificates queryCertFilter Parameters
Parameter
Expression Values
Value: date (number of seconds since Jan 1, 1970)
A date object can be created using the JavaScript Date() constructor.
This parameter matches the date a certificate was issued. For example, to find certificates created during 1999:
Object lowDate = new Date(1999,00,01);
Object highDate = new Date(1999,11,31);
form.queryCertFilter.value =
"(&(certCreateTime>=" + lowDate + ")" +
"(certCreateTime<=" + highDate + ")";
Value: user ID of an agent issuing a certificate
Use the asterisk (*) wildcard to match partial names. For example, (certIssuedBy=localAgent*).
Value: number in decimal or hexadecimal.
This parameter matches the serial number on a certificate. Connect a lower and upper bound with a logical AND (&) to specify a bounded range of serial numbers. For example:
Value: user ID of an agent that revoked a certificate
Use the asterisk (*) wildcard to match partial names. For example, (certRevokedBy=localAgent*).
Value: date (number of seconds since Jan 1, 1970)
A date object can be created using the JavaScript Date() constructor.
This parameter matches the date when a certificate was revoked. See certCreateTime for an example of creating a date value in JavaScript
Value: * | EXPIRED | INVALID | REVOKED | VALID | REVOKED_EXPIRED
This parameter matches the current status of a certificate. The asterisk (*) matches any status.
Value: * | number between 0 and 6
This parameter matches the reason for revocation code on a certificate. The revocation codes are:
To search for multiple values, construct a filter with multiple x509cert.certRevoInfo parameters connected with a logical OR. Do not connect these parameters with an AND, since a certificate cannot have more than one revocation reason. For example, to match certificates revoked due to key compromise or an unspecified reason:
This parameter matches the total number of milliseconds of a certificates validity period. Typically a range is specified using filters with >= and <= operators, rather than an exact match. The following list shows the number of milliseconds in some typical time intervals:
Value: date (number of seconds since Jan 1, 1970)
A date object can be created using the JavaScript Date() constructor.
This parameter matches the date when a certificate expires. See certCreateTime for an example of creating a date value in JavaScript
Value: date (number of seconds since Jan 1, 1970)
A date object can be created using the JavaScript Date() constructor.
This parameter matches the date when a certificate became valid. See certCreateTime for an example of creating a date value in JavaScript
This parameter matches the bit in the ns-cert-type extension specified by the extension <X>.
Substitute an extension identifier for <X>:
SecureEmail - for S/MIME certificates
SSLClient - for SSL client certificates
SSLServer - for SSL server certificates
SubordinateEmailCA - for certificates with the S/MIME CA bit set
For example, to match only certificates with the SSL client bit (bit 0) set in the ns-cert-type extension:
Value: a pattern that may include the wildcard (*)
This parameter matches the certificate subject DN. You can use a single filter or connect multiple filters to build more complex DN patterns.
The value is typically a string in the form *<TAG>=<VALUE>*. The asterisks allow the name-value pair to be matched at any location in the DN. The tag is one of the subject DN attributes: CN, E, UID, OU, O, L, ST, C.
To allow partial matches, use the wildcard in the attribute value. For example, to match email addresses containing "jdoe,"
To force an exact match of "jdoe@example.com," you should still use the wildcard to allow the E attribute to occur anywhere in the DN:
(|(x509cert.subject=*E=jdoe@example.com,*)
(x509cert.subject=*E=jdoe@example.com))
Response
The default response template is queryCert.template. The base JavaScript for responses is inserted in place of the <CMS_TEMPLATE> tag. In addition, the Revocation interface adds the JavaScript variables listed in the following table:
Available on: Certificate Manager or Registration Manager
Function: Processes requests for certificate renewal.
The Renewal interface allows an end entity to present a certificate and have it renewed. Only certificates that can be used for SSL client authentication can be renewed using the Renewal interface.
Default Forms
The only default form used by the Renewal interface is UserRenewal.html. This form allows a user to renew a certificate using SSL client authentication.
Request Parameters
The following table lists the parameters accepted by the Renewal interface.
Response
Responses from the Renewal interface are functionally equivalent to the Enrollment interface. Once the request has been submitted, the role of the Certificate Manager or Registration Manager is the same as if the request were for enrollment: the CMS server either rejects the request, queues it for manual processing, or issues a certificate.
The only difference in the response is for a successful request. The Renewal interface uses the RenwalSuccess.template file by default instead of EnrollSuccess.template. The difference between these two files (by default) is superficial: the word "Enrollment" is replaced with the word "Renewal." If you want to customize the renewal success message, customize the RenewalSuccess.template file.
Except for template for a successful request, the Renewal interface response is identical to the Enrollment interface response.
Refer to the Response section of the Enrollment Interface section for complete details on the data returned and templates used.
Available on: Certificate Manager or Registration Manager
Function: Allows automatic revocation of certificates by client authentication (an entity can revoke a certificate it presents).
The response is always a form that indicates the status of the revocation request (revoked, pending, or error), the result of updating the Certificate Revocation List, and the result of updating the certificate directory (if publishing is enabled).
Default Forms
The Revocation interface uses the UserRevocation.html form by default. This form posts requests that use SSL client authentication to present the certificate to be revoked. The certificate is automatically revoked.
Request Parameters
The following table lists the parameters accepted by the Revocation interface.
Response
The default response template is revocationResult.template. The base JavaScript for responses is inserted in place of the <CMS_TEMPLATE> tag. In addition, the Revocation interface adds the JavaScript variables listed in the following table:
Previous Contents Index Next
Copyright © 2002 Sun Microsystems, Inc. All rights reserved.
Last Updated October 07, 2002