Administrator's Guide Netscape Certificate Management System

Previous      Contents      Index      DocHome      Next

Chapter 5   OCSP Responder

This chapter provides an overview of an Online Certificate Status Protocol (OCSP) service, and explains how you can use the OCSP service built into the Certificate Manager for real-time verification of certificates issued by the Certificate Manager. The chapter also explains how to install and configure an Online Certificate Status Managers to publish CRLs.

This chapter contains the following sections:

• About OCSP Services
• CMS OCSP Services
• Setting Up a Certificate Manager with OCSP Service
• Online Certificate Status Manager Deployment Considerations
• Installing an Online Certificate Status Manager
• Setting Up the OCSP Responder
• Configuring the Online Certificate Status Manager
• Testing Your OCSP Setup

About OCSP Services

---

CMS supports the Online Certificate Status Protocol (OCSP) as defined in the PKIX standard RFC 2560 (see http://www.ietf.org/rfc/rfc2560.txt). The OCSP protocol enables OCSP-compliant applications to determine the state of a certificate, including the revocation status, without having to directly check a CRL published by a CA to the validation authority. The validation authority, which is also called an OCSP responder, does the checking for the application.

How OCSP Services Work

An OCSP service works as follows:

1. A CA is set up to issue certificates that include the Authority Information Access Extension whose value identifies an OCSP responder that can be queried for the status of the certificate.
2. One or more CAs periodically publishes CRLs to an OCSP responder.
3. The OCSP responder maintains the CRL it receives from the CA(s).
4. An OCSP-compliant client verifies the status of a certificate by sending requests containing all the information required to identify the certificate to the OCSP responder for verification. The applications determine the location of the OCSP responder from the value of the Authority Information Access Extension in the certificate being validated.
5. The OCSP responder determines if the request contains all the information required by the responder to process it. If it does not, or if it is not enabled for the requested service, a rejection notice is sent. If it does have enough information, it processes the request and sends back a report stating the status of the certificate. See "OCSP Responses" for details on the responses sent by an OCSP service.

OCSP Response Signing

Every response that the client receives, including a rejection notification, is digitally signed by the responder; the client is expected to verify the signature to ensure that the response came from the responder to which it submitted the request. The key the responder uses to sign the message depends on how the OCSP responder is deployed in a PKI setup. RFC 2560 recommends that the key used to sign the response belong to one of the following:

• The CA that issued the certificate and whose status is being verified by the responder.
• A responder whose public key, which corresponds to the private key it uses to sign responses, is trusted by the client. Such a responder is called a trusted responder.
• A responder that holds a specially marked certificate issued to it directly by the CA that revokes the certificates and publishes the CRL. Possession of this certificate by a responder indicates that the CA has authorized the responder to issue OCSP responses for certificates revoked by the CA. Such a responder is called a CA-designated responder or a CA-authorized responder.

CMS has a built-in OCSP responder and allows you to request OCSP responder certificates. The end-entity interface of both Registration Manager and Certificate Manager includes a form that allows you to manually request a certificate for the OCSP responder. The default enrollment form includes all the attributes (for example, HTTP_PARAMS.certType==ocspResponder) that identify the certificate as an OCSP responder certificate. The required policies extensions, such as OCSPNoCheck, ExtendedKeyUsageExt with RuleID, and OCSPSigning, can be added to the certificate when the certificate request is subjected to policy checking; see Configuring Policy Rules for a Subsystem.
 

For more information about the certificates associated with OCSP, see "SSL Server Key Pair and Certificate".

OCSP Responses

The OCSP response that the client receives indicates the current status of the certificate as determined by the OCSP responder. The response could be any of the following:

• Good or Verified—specifying a positive response to the status inquiry. At a minimum, this positive response indicates that the certificate has not been revoked, but it does not necessarily mean that the certificate was ever issued or that the time at which the response was produced is within the certificate's validity interval. Response extensions may be used to convey additional information on assertions made by the responder regarding the status of the certificate such as positive statement about issuance, validity, etc.
• Revoked—specifying that the certificate has been revoked, either permanently or temporarily.
• Unknown—specifying that the OCSP responder doesn't know about the certificate whose status is being requested by the client.

Based on the status, the client decides whether to validate the certificate.

CMS OCSP Services

---

To aid you in the process of setting up a OCSP-compliant PKI setup, CMS provides two options:

• The OCSP-service feature built into the Certificate Manager
• The Online Certificate Status Manager

How Certificate Manager's OCSP-Service Feature Works

The Certificate Manager has a built-in OCSP-service feature, which when configured, can be used by OCSP-compliant clients to directly query the Certificate Manager about the revocation status of the certificate being validated. The OCSP service is installed and configured by default, and is one of the options during install. Unless you deselected this option, the service was installed and configured.

Clients can query the OCSP through the non-SSL end-entity port of the Certificate Manager. When queried for the revocation status of a certificate, the Certificate Manager looks up its internal database for the certificate, checks its status, and accordingly responds to the client. Since the Certificate Manager has real-time status of all certificates it has issued, this method of revocation checking is most accurate.

Since the internal OCSP service checks the status of certificates stored in the Certificate Manager's internal database, you do not need to set up publishing to use this service. The certificates are stored, and revoked certificates are marked revoked in the internal database of the Certificate Manager by default.

For step-by-step instructions to set up an OCSP-compliant PKI setup using the Certificate Manager, see Setting Up a Certificate Manager with OCSP Service.

How the Online Certificate Status Manager Works

In addition to the built-in OCSP service feature, the Certificate Manager can also publish CRLs to an OCSP-compliant online validation authority. If you install the CMS OCSP responder, Online Certificate Status Manager, you can configure one or more Certificate Managers to publish their CRLs to the Online Certificate Status Manager. The Online Certificate Status Manager stores each Certificate Manager's CRL in its internal database and uses the appropriate CRL to verify the revocation status of a certificate when queried by an OCSP-compliant client. (Note the difference between the Online Certificate Status Manager and the internal OCSP service. The internal OCSP service checks certificate status by checking the internal database of the Certificate Manager. The Online Certificate Status Manager checks certificate status by checking CRLs provided by the Certificate Manager that it stores in its own internal database.)

You can configure the Certificate Manager to generate and publish CRLs whenever a certificate is revoked and at specified intervals, say every 20 minutes. Because the purpose of setting up an OCSP responder is to facilitate real-time verification of certificates, you should configure the Certificate Manager to generate and publish the CRL to the Online Certificate Status Manager every time a certificate is revoked—configuring the Certificate Manager to publish CRLs at specific intervals would negate the very purpose for which it's being done because the CRL the Online Certificate Status Manager would look up during verification would always be outdated. It's important to note that if the CRL is large, the Certificate Manager could take a considerable amount of time to publish the CRL.

As explained earlier, the Online Certificate Status Manager stores each Certificate Manager's CRL in its internal database and uses it as the default CRL store for verifying certificates. You can also configure the Online Certificate Status Manager to use the CRL published to an LDAP directory by a Certificate Manager. In this case, the Certificate Manager does not have to update the CRLs the Online Certificate Status Manager, it updates them to the LDAP directory which the Online Certificate Status Manager is able to read. If you do so, the Online Certificate Status Manager uses the CRL published to the LDAP directory, instead of the CRL in its internal database.

For step-by-step instructions to set up an OCSP-compliant PKI setup using the Online Certificate Status Manager, see Installing an Online Certificate Status Manager.

Setting Up a Certificate Manager with OCSP Service

---

The Certificate Manager has a built-in OCSP service feature that can be used by OCSP-compliant clients to do real-time verification of certificates issued by the Certificate Manager. This section explains how to setup an OCSP-compliant PKI setup using the Certificate Manager's OCSP-service feature.

You must have OCSP-compliant clients in order to be able to use the OCSP service.

1. Make sure the OCSP service for the CA is enabled.
2. Set up CRLs. You need to configure the Certificate Manager to issue CRLs. See Chapter 15 "Revocation and CRLs" for details on configuring CRLs.
3. You must configure your policies or certificate profiles to include the Authority Information Access extension pointing to the location at which the Certificate Manager listens for OCSP service requests (identified as the AuthInfoAccessExt instance in the policy framework.) in certificates that are issued. This extension is necessary to identify the OSCP service. If you installed the Certificate Manager with the OSCP service on, this extension is created with the correct information for the OSCP service in the policy framework, and is not enabled by default. If you chose not to configure the OSCP service, you will have to create this policy and configure it for this service.

If you installed the Certificate Manager's with its OCSP service feature disabled, a default policy rule (named AuthInfoAccessExt) is created, but it may not have the correct attributes for adding the Authority Information Access extension to certificates.
 

See Chapter 12 "Policies" for details on configuring policies, see "AuthInfoAccessExt" for specific information on this policy module.
 

4. Make sure the OCSP SSL signing certificate is from a CA that is trusted by the Certificate Manager. See "OCSP Certificates" for more information.

Online Certificate Status Manager Deployment Considerations

---

This section describes the decisions you make during installation that will apply to your initial configuration of the subsystem.

Online Certificate Status Manager Certificates

When you install the Online Certificate Status Manager, the keys for the OCSP signing certificate and SSL server certificate are created and a certificate request is made for the signing certificate and the SSL server certificate.

You submit this request either to a CMS CA, or you submit the request to a third party public CA and then install the certificate you receive from the CA during the rest of the installation. If you submit the request to a CMS CA, the installation program will allow you submit the request to the CA in the install wizard, and pick up the certificate once it is approved.

OCSP Signing Key Pair and Certificate

Every Online Certificate Status Manager you have installed has a certificate, identified as the Online Certificate Status Manager signing certificate, whose public key corresponds to the private key the Online Certificate Status Manager uses to sign OCSP responses before sending them to OCSP-compliant clients. The Online Certificate Status Manager's signature provides persistent proof to an OCSP-compliant client that the Online Certificate Status Manager has processed the request. The first time you generated this certificate is when you installed the Online Certificate Status Manager. The default nickname for the certificate is ocspSigningCert cert-<instance_id>, where <instance_id> identifies the CMS instance in which the Online Certificate Status Manager is installed.

The Online Certificate Status Manager's signing certificate was issued by the CA to which you submitted the certificate signing request.

SSL Server Key Pair and Certificate

Every Online Certificate Status Manager you have installed has at least one SSL server certificate. The first time you generated this certificate is when you installed the Online Certificate Status Manager. The default nickname for the certificate is Server-Cert cert-<instance_id>, where <instance_id> identifies the CMS instance in which the Online Certificate Status Manager is installed.

The Online Certificate Status Manager's SSL server certificate was issued by the CA to which you submitted the certificate signing request. You might have submitted the request to an internally deployed CA or a public CA.

The Online Certificate Status Manager uses its SSL server certificate to do SSL server-side authentication for the Online Certificate Status Manager Agent Services interface.

By default, the Online Certificate Status Manager uses a single SSL server certificate for authentication purposes. However, you can request and install additional SSL server certificates for the Online Certificate Status Manager. For example, you can configure the Online Certificate Status Manager to use separate server certificates for the Netscape Console and the Online Certificate Status Manager Agent Services interfaces. For instructions, see Configuring the Server's Security Preferences.

Interfaces

When you install an Online Certificate Status Manager, three interfaces are enabled. The installation wizard lets you choose the ports these interfaces listen on. The following interfaces, and associated ports will be created:

• An Administrative interface that is accessible by default only to members of the Administrator and Auditor group. Administrators can configure any of the settings of the server. Most basic functionality and subsystem specific configuration to the subsystem can be done using the administrative interface.

The administrative interface listens to requests on the SSL Administration Port. This is the port the CMS administrative interface listens to, and that is accessed by administrators and auditors using the Java based CMS Console GUI application.
 

• An Agent Services interface that is accessible by default only to members of the Online Certificate Status Manager Agent group. The agent's services interface is an HTML interface accessible through HTTPS that authenticates agents using their certificates. The default interface provides all the functionality needed by agents for a Online Certificate Status Manager and is completely customizable.

The agent services interface listens to requests and communicates on the SSL Agent Services Port. This is the port that the agent goes to in order to access the agent services interface. The agent services interface is accessible at the following location:
 

https://<cms_host_dnsname>:<port_number>
 

For example:
 

https://services.example.com:7878
 

• An End-Entity interface that is accessible by anyone who can access that URL. The end-entity interface listens for requests on the SSL or Non-SSL End Entity Ports. It does not contain HTML forms, but is used for requests to the OCSP responder. Both are configured during installation.

https://<cms_host_dnsname>:<port_number>
 

For example:
 

https://services.example.com:7172
 

Password Storage

Each subsystem stores passwords for its internal database, and for the tokens containing its keys and certificates. See "System Passwords" for information on how these passwords are stored.

Tokens

You choose either the internal token (if you plan to use the internal/software token) or an external token to store the signing certificate and key pair and the SSL signing certificate and key pair.

If you are using an external token, you will need to install it before you run the Installation Wizard. In the wizard, you can select from a list of already installed and available tokens. For example, HSM. For installation instructions, see External Token.

Internal Database

Each subsystem uses an internal database to store information (such as certificates and certificate requests) used by the subsystem you will be installing in this CMS instance. By default, a separate internal database is created for each subsystem you configure. You can choose to use the same internal database for more than one subsystem by specifying this when running the installation wizard to configure that subsystem. You should carefully consider whether you want to store this information in a separate internal database for each subsystem or use one internal database for all subsystems installed on the host.

It's recommended that you do not use this Directory Server instance for any other purposes; the directory schema will be configured for storing CMS data.

Signing Key Type and Length

If you wish, you can import the signing key and certificate used in a previous version of CMS installation rather than generating a new signing key pair. For information on how to do this, check the migration information in Step 6 of the section "Upgrading" in Chapter 2 of the Command-Line Tools Guide.

If you decide to generate a new signing key, one of the first decisions you need to make is whether to use the RSA or DSA algorithm. If you use DSA, the software can generate and verify the PQG value. PQG values are used to create the DSA signing key pair. For more information about the way they are used, check this document: http://www.itl.nist.gov/div897/pubs/fip186.htm.

In general, longer keys are considered to be cryptographically stronger than shorter keys. However, longer keys also require more time for signing operations.

Many people no longer consider an RSA key of length less than 1024 bits to be cryptographically strong. Export and other regulations permitting, it may be a good rule of thumb to start with 1024 bits and consider increasing the length to 4096 bits for certificates that provide access to highly sensitive data or services. (CMS signing keys up to 2048 bits in length are not subject to export restrictions.) However, the question of key length has no simple answers. Every organization must make its own decision based on its own security requirements. For more information on key length and encryption strength, see Appendix D of Managing Servers with Netscape Console.

Installing an Online Certificate Status Manager

---

To install a standalone Online Certificate Status Manager:

1. Log into Netscape Console as the administrator.
2. Select the CMS instance and then either click Open, or double click this instance.

The Installation Wizard launches.
 

3. Installation Wizard Introduction. Click Next to continue.
4. Logon Token. Enter either internal (if you plan to use the internal/software token) or the name of an external token to store the Certificate Manager signing certificate and key pair. If you have not previously initialized the token's password, you must do so in this screen. See "Tokens" for more information.
5. Internal Database. Choose to either create a new internal database for this instance or to use an existing Directory Server instance as the internal database for this instance. Next, specify the information for that Directory Server instance. See "Internal Database" for more information.

Click Next to continue. The wizard sets up the new internal database, which takes some time.
 

Click Next to continue.
 

6. Administrator. Type the user ID, name and password for the CMS administrator. This user ID will be set up as the administrator who can access the CMS window and control all CMS settings.

Allow Multiple Roles for Users. Select if you want to allow users to belong to more than one group, thus assuming more than one role. Deselect if you want to restrict users from being able to belong to more than one role. This setting only applies to the default administrator, agent, auditor roles.
 

Click Next to continue.
 

7. Subsystems. Choose a subsystem you want to install.

Select Online Certificate Status Manager.
 

Click Next to continue.
 

8. Network Configuration. Type the numbers for the ports to be used by the CMS instance. The OCSP-compliant clients will use this port to communicate with the Online Certificate Status Manager.

Click Next to continue.
 

9. Key-Pair Information for Online Certificate Status Manager Signing Certificate.
• Token. Enter either internal (if you plan to use the internal/software token) or the name of an external token to store the Online Certificate Status Manager signing certificate and key pair. If you have not previously initialized the token's password, you must do so in this screen. See "Tokens" for more information.
• Key Type. Choose RSA or DSA.
• Key Length. Available key sizes for RSA are 512, 768, 1024, 2048, 4096, or Custom. Available key sizes for DSA are 512, 1024, or Custom (which must be in increments of 64 bits only).

See Signing Key Type and Length for more information.
 

Click Next to continue.
 

10. Subject Name for Online Certificate Status Manager Signing Certificate. Type the values for the subject DN components; these values identify the Online Certificate Status Manager's signing certificate.

Click Next to continue.
 

11. Online Certificate Status Manager Signing Certificate Request Creation. This informational screen tells you that the wizard has all the information required to generate the key pair and certificate request.

Click Next to generate them.
 

12. Submission of Request. Select whether you want to submit the request manually or send the request to a remote CMS manager (Certificate Manager or Registration Manager) automatically. The wizard creates a certificate request that you must submit to a CA.
• To automatically submit the request to a remote Certificate Manager (or for automatic enrollment), follow these steps:
1. Select the "Send the request to a remote CMS now" option.
2. Enter the host name (for example, host.domain.com) and end-entity port number of the Certificate Manager, then specify whether this end-entity port uses SSL.
3. Click Next to submit the request.

The Certificate Request Result screen appears, confirming that the request has been submitted. Note the request ID provided in the response message. (You can use it later to retrieve the certificate, once the certificate has been issued, from the end-entity port.)
 

Note that your request gets added to the agent queue of the Certificate Manager for approval by that Certificate Manager's agent. If you've permission to access that Certificate Manager's Agent interface, you can follow the instructions below to issue the certificate. Otherwise, you should wait for the other agent to approve the request you submitted and issue the certificate.
 

4. Open a web browser window.
5. Enter the URL for the Certificate Manager's Agent Services page. (You must authenticate using your agent certificate.)
6. Select List Requests, then click Show Pending Requests and click Find. The pending request list is displayed.
7. Locate your request, click Details to see it, and make any changes. Then, scroll down to the bottom of the form and click Accep this request.
8. After the certificate is generated, click Show Certificate.
9. When the certificate is displayed, scroll down to the base-64 encoded version of the certificate, highlight all the text (including -----BEGIN CERTIFICATE ----- and -----END CERTIFICATE-----), and copy it to the clipboard or to a text file.

Be sure to not make any changes to the certificate. You're required to paste the encoded certificate into the Installation Wizard next. So, once you've copied the certificate, go back to the wizard screen (Step 13).
 

Also note that you might be required to paste the CA certificate chain in the Installation Wizard. So, keep the browser window open.
 

• To submit your certificate request manually to a Certificate Manager, follow these steps:
1. Open a web browser window.
2. Go to the end-entity URL for the Certificate Manager that will issue the Online Certificate Status Manager's signing certificate.

For example, if you assigned the port number 17006 to the non-SSL end-entity port for your CA, you would go to the URL http://<hostname>:17006 to bring up the Certificate Manager page for end entities.
 

3. Click Manual OCSP Manager Signing Certificate Enrollment.
4. In the OCSP Responder Enrollment page that appears, paste the request from the clipboard into the field labeled PKCS #10 Request and fill in any other required information.
5. Click Submit.
6. If the request contains all the required information, you'll get a notification of request being successfully added to the agent queue of that Certificate Manager for approval by that Certificate Manager's agent. If you've permission to access that Certificate Manager's Agent interface, you can follow the instructions below to issue the certificate.
7. In the web browser window, enter the URL for the Certificate Manager's Agent Services page. (You must have a valid agent's certificate.)
8. Select List Requests, then click Show Pending Requests and click Find. The pending request list is displayed.
9. Locate your request, click Details to see it.
10. After checking the rest of the certificate request and making any changes, scroll to the bottom, and click Approve Request.
11. When the certificate is displayed, scroll down to the base-64 encoded version of the certificate, highlight all the text (including -----BEGIN CERTIFICATE ----- and -----END CERTIFICATE-----), and copy it to the clipboard or to a text file.

Be sure to not make any changes to the certificate. You're required to paste the encoded certificate into the Installation Wizard next. So, once you've copied the certificate, go back to the wizard screen (Step 13).
 

Also note that you might be required to paste the CA certificate chain in the Installation Wizard. So, keep the browser window open.
 

• To submit your certificate request manually to a third-party CA, follow these steps:
1. Make sure that the certificate request (including -----BEGIN NEW CERTIFICATE REQUEST ----- and -----END NEW CERTIFICATE REQUEST -----) is highlighted, and click the Copy to Clipboard button.

This action copies the certificate request to the clipboard. In addition to the copy on the clipboard, the screen informs you that the certificate request has been saved to a file. You can use either the copy on the clipboard or the copy in the file to transfer your request to the CA that will issue the Online Certificate Status Manager's signing certificate.
 

2. Submit your certificate request to a third-party CA, following the instructions provided by that CA.

Click Next when you are ready to proceed.
 

13. Online Certificate Status Manager Signing Certificate Installation. Depending on whether you have the certificate ready for pasting into the Installation Wizard screen, click Yes or No.
• Select No if you have submitted your request to a third-party CA or to a remote Certificate Manager for which you do not have agent privileges, you may have to wait days or weeks before you receive the certificate. Continue as far as you can with the configuration, and resume after you receive the certificate. The default selection is No.
• Select Yes if you have the certificate ready in its base-64 encoded format.

Click Next to continue.
 

• If you selected Yes, the "Location of Certificate" screen appears (Step 14).
• If you selected No, you will be presented with the "Key-Pair Information for SSL Server Certificate" screen (Step 17).
14. Location of Certificate. Specify the location of the certificate. You can use one of these options:
• If you noted the file path to the file that contains the certificate (in its base 64-encoded format), select the "The certificate is located in this file" option and type the file path, including the filename, in the text field.
• If you copied the certificate (in its base 64-encoded format) to the clipboard, select the "The certificate is located in the text area below" option and paste the certificate (including the header and footer) in the text area provided.
• If you want the wizard to retrieve the certificate from the remote CMS manager to which you submitted the request, select the "The certificate is at the CMS where the request was sent" option and supply the host name, end-entity port number, and request ID.

Click Next to continue.
 

15. Certificate Details. This is an informational screen that displays the certificate so you can inspect its contents. Notice the nickname assigned to the certificate and verify that you're installing the correct certificate.

Click Next to continue.
 

16. Import Certificate Chain. This screen appears only if you need to import the CA certificate chain. Follow these steps to import the CA chain of a Certificate Manager:
1. Go back to the web browser window from which you copied the Online Certificate Status Manager's signing certificate (in its base-64 encoded format).
2. Scroll down to the part that says "Base 64 encoded certificate with CA certificate chain in pkcs7 format" and shows the CA certificate chain in its PKCS#7 format.
3. Highlight all the encoded blob (including -----BEGIN CERTIFICATE ----- and -----END CERTIFICATE-----), and copy it to the clipboard or to a text file.

Be sure to not make any changes to the certificate. You're required to paste the encoded certificate into the Installation Wizard next. So, once you've copied the certificate, go back to the wizard screen.
 

4. Paste the certificate chain into the text box.
5. Click Next to continue.

If you closed the end-entity interface, you can get the CA certificate chain this way:
 

1. Open a web browser window.
2. Go to the end-entity URL for the Certificate Manager that issued the Online Certificate Status Manager's signing certificate.
3. Select the Retrieval tab, and then choose Import CA Certificate Chain.
4. Select the "Display the CA certificate chain in PKCS#7 for importing into a server" option, and then click Submit.
5. Copy the certificate chain to the clipboard.
6. Return to the Installation Wizard.
7. Paste the certificate chain into the text box.
8. Click Next to continue.
17. Key-Pair Information for SSL Server Certificate.
• Token. Enter either internal (if you plan to use the internal/software token) or the name of an external token to store the SSL server certificate and key pair. If you have not previously initialized the token's password, you must do so in this screen. See "Tokens" for more information.
• Key Type. Choose RSA .
• Key Length. Available key sizes for RSA are 512, 768, 1024, 2048, 4096, or Custom. Available key sizes for DSA are 512, 1024, or Custom (which must be in increments of 64 bits only).

See Signing Key Type and Length for more information.
 

Click Next to continue.
 

18. Subject Name for SSL Server Certificate. Type the values for the subject DN components; these values identify the Online Certificate Status Manager's SSL server certificate. The CN must be the fully-qualified host name of the machine on which you're installing the Online Certificate Status Manager.

Click Next to continue.
 

19. Certificate Extensions for SSL Server Certificate. Select the required extensions. The default settings should work for most deployments. If necessary, you can add an additional extension by pasting its base-64 encoding in the space provided on this screen.

CMS provides command-line tools for generating extensions to include in CA and other certificate requests. For details about these tools, check this directory: <server_root>/bin/cert/tools
 

Note that the certificate extension text field accepts a single extension blob. If you want to add multiple extensions, you should use the ExtJoiner program, which is also provided in the tools directory. For details on using the ExtJoiner program, see Chapter 5, "Extension Joiner Tool" of CMS Command-Line Tools Guide.
 

Click Next to continue.
 

20. SSL Server Certificate Request Creation. This is an informational screen that tells you that the wizard has all the information required to generate the key pair and certificate request. In the previous screen, if you chose to include the Subject Key Identifier extension in the certificate, you'll be given the choice to select the format for the certificate request. Otherwise, the request format will be PKCS #10.
• If you want the wizard to generate the certificate request in PKCS #10 format, select the "Generate PKCS10 request" option.
• If you want the wizard to generate the certificate request in CMC format, select the "Generate CMC full enrollment request" option.

Click Next. The wizard generates the certificate request that you must submit to a CA.
 

21. Submission of Request. Select whether you want to submit the request manually or send the request to a remote CMS server (Certificate Manager or Registration Manager) automatically.
• To automatically submit the request to a remote Certificate Manager (or for automatic enrollment), follow these steps:
1. Select the "Send the request to a remote CMS now" option.
2. Enter the host name and end-entity port number of the Certificate Manager, and select whether this end-entity port uses SSL.
3. Click Next to submit the request.

The Certificate Request Result screen appears, confirming that the request has been submitted. Note the request ID provided in the response message. (You can use it later to retrieve the certificate, once it has been issued, from the end-entity port.)
 

Note that your request gets added to the agent queue of the Certificate Manager for approval by that Certificate Manager's agent. If you've permission to access that Certificate Manager's Agent interface, you can follow the instructions below to issue the certificate. Otherwise, you should wait for the other agent to approve your request and issue the certificate.
 

4. In the web browser window, enter the URL for the Certificate Manager's Agent Services page. (You must have a valid agent's certificate.)
5. Select List Requests, then click Show Pending Requests and click Find. The pending request list is displayed.
6. Locate your request, click Details to see it, and make any changes. Then scroll down to the bottom of the form and click Accept this request.
7. After the certificate is generated, click Show Certificate.
8. When the certificate is displayed, scroll down to the base-64 encoded version of the certificate, highlight all the text (including -----BEGIN CERTIFICATE ----- and -----END CERTIFICATE-----), and copy it to the clipboard or to a text file.

Be sure to not make any changes to the certificate. You're required to paste the encoded certificate into the Installation Wizard next. So, once you've copied the certificate, go back to the wizard screen (Step 22).
 

• To submit your certificate request manually to a Certificate Manager, follow these steps:
1. Open a web browser window.
2. Go to the end-entity URL for the Certificate Manager that will issue the SSL server certificate.

For example, if you assigned the port number 17006 to the non-SSL end-entity port for your root CA, you would go to the URL http://<hostname>:17006 to bring up the Certificate Manager page for end entities.
 

3. Click Manual Server Certificate Enrollment, or click Agent-Based Server Certificate Enrollment if you have an agent certificate. If you choose Agent-Based Server Certificate Enrollment and you have an agent certificate, the certificate will be automatically issued once you submit the request.

In the resulting form, choose the type of request from the pull down menu, paste the request in the request field, and fill in the other fields on the form.
 

4. Click Submit.
5. If you used the Agent-Based Server Certificate Enrollment and you have an agent certificate, the certificate will be automatically issued once you submit the request.

If you used the Manual Server Certificate Enrollment request, the request gets added to the agent queue of that Certificate Manager for approval by that Certificate Manager's agent. If you've permission to access that Certificate Manager's Agent interface, you can follow the instructions below to issue the certificate. Otherwise, you'll have to wait for the Certificate Manager's agent to approve your request and issue the certificate.
 

To approve the request, do the following:
 

In the web browser window, enter the URL for the Certificate Manager's Agent Services page. (You must have a valid agent's certificate.)
 

Select List Requests, then click Show Pending Requests and click Find. The pending request list is displayed.
 

Locate your request, click Details to see it, and make any changes. Then, scroll down to the bottom of the form, select the appropriate action.
 

6. In the web browser window, enter the URL for the Certificate Manager's Agent Services page. (You must have a valid agent's certificate.)
7. Select List Requests, then click Show Pending Requests and click Find. The pending request list is displayed.
8. Locate your request, click Details to see it, and make any changes. Then, scroll down to the bottom of the form and click Approve Request.
22. SSL Server Certificate Installation. Depending on whether you have the certificate ready for pasting into the Installation Wizard screen, click Yes or No.
• If you have submitted your request to a third-party CA or to a remote Certificate Manager for which you do not have agent privileges, you may have to wait days or weeks before you receive the certificate. In this case, you should click No, continue as far as you can with the configuration, and resume after you receive the certificate. The default is No.
• Select Yes, only if you have the certificate ready in its base-64 encoded format.

Click Next to continue.
 

• If you selected Yes, the "Location of Certificate" screen appears (Step 23).
• If you selected No, you will be presented with the "Create Single Signon Password" screen (Step 26).
23. Location of Certificate. Specify the location of the certificate. You can use one of these options:
• If you copied the encoded certificate to a file, select the "The certificate is located in this file" option and type the file path, including the filename, in the text field.
• If you copied the certificate to the clipboard, select the "The certificate is located in the text area below" option and then paste in a base-64 encoded certificate (including the header and footer) in the text area provided.
• If you know the request ID of your request and the host name and end-entity port number of the Certificate Manager that issued the SSL server certificate, select the "The certificate is at the CMS server where the request was sent" option and then specify the required details.

Click Next to continue.
 

24. Certificate Details. This is an informational screen that displays the certificate so you can inspect its contents. Notice the nickname assigned to the certificate and verify that you're installing the correct certificate.

Click Next to continue.
 

25. Import Certificate Chain. This screen appears only if you need to import the CA certificate chain. Follow these steps to import the CA chain of a Certificate Manager:
1. Go to the web browser window.
2. Enter the end-entity URL for the Certificate Manager that issued the SSL server certificate.
3. Select the Retrieval tab, and then choose Import CA Certificate Chain.
4. Select the "Display the CA certificate chain in PKCS#7 for importing into a server" option, and then click Submit.
5. Copy the certificate chain to the clipboard.
6. Return to the Installation Wizard.
7. Paste the certificate chain into the text box.
8. Click Next to continue.
26. Single Signon Summary. Check the summary and select whether to retain or delete the password.conf file.

The single signon password simplifies the way you subsequently sign on to CMS by storing the passwords for the internal database, tokens, and so on. Each time you log on, you're only required to enter this single password. (For details, see System Passwords.)
 

Click Next to continue.
 

27. Configuration Status. This screen should indicate that your configuration has been successful and that you need to create an agent for the Online Certificate Status Manager.

Click Done to exit the Installation Wizard.
 

28. You now need to create the first agent user for the Online Certificate Status Manager. See "Agent Certificates" for details.

Setting Up the OCSP Responder

---

In order to properly set up the Online Certificate Status Manager, you must set up the following:

1. Configure every CA that will publish to the OCSP Responder to Publish CRLs. See Chapter 15 "Revocation and CRLs" for complete details.
2. Enable Publishing and set up a publisher and a publishing rule(s) to publish CRLs to the Online Certificate Status Manager in every CA that the OCSP will handle. See Chapter 16 "Publishing" for complete details. (You do not need to do this if the Certificate Manager publishes to an LDAP directory and the Online Certificated Status Manager is set up to read from that LDAP publishing directory.)
3. You must configure your policies or certificate profiles for every CA that will publish to the OCSP Responder to include the Authority Information Access extension pointing to the location at which the Certificate Manager listens for OCSP service requests (identified as the AuthInfoAccessExt instance in the policy framework.) in certificates that are issued. This extension is necessary to identify the OSCP service. If you installed the Certificate Manager with the OSCP service on, this extension is created with the correct information for the OSCP service. If you chose not to configure the OSCP service, you will have to create this policy and configure it for this service.

If you installed the Certificate Manager's with its OCSP service feature disabled, a default policy rule (named AuthInfoAccessExt) is created, but it may not have the correct attributes for adding the Authority Information Access extension to certificates.
 

See Chapter 12 "Policies" for details on configuring policies, see "AuthInfoAccessExt" for specific information on this policy module.
 

4. Configure the OCSP Responder. See "Configuring the Online Certificate Status Manager". Pay close attention to configuring the following:
• Configure the Revocation Info stores. See "Configure the Revocation Info Stores".
• Identify every Certificate Manager that will publish to the OCSP Responder to the OCSP Responder. "Identifying the CA to the OCSP Responder" for complete details.
• You may need to configure trust settings depending on who signed the OCSP signing certificate. See "OCSP Certificates" for details.
5. After configuring both the Certificate Manager and the Online Certificate Status Manager, restart both.
6. To verify that the CA is properly connected to the OCSP responder, see "Verify Certificate Manager and Online Certificate Status Manager Connection".

Configuring the Online Certificate Status Manager

---

This section details the areas that you can configure for the Online Certificate Status Manager and points you to specific information on configuring those sets of features.

Adding Users

Once the Online Certificate Status Manager is installed, you need to add users and assign them to the administrator, agent, and auditor roles. See Chapter 9 "Authorization" for details on adding users and assigning them to groups.

Configuring Authorization

Each subsystem has a set of predefined groups that are assigned a default set of privileges. You create users in the CMS database and then assign them to that group to give them the privileges of that group. The privileges assigned to a role are controlled by Access Control Instructions (ACIs) placed in Access Control Lists (ACLs). ACLs define points that need specific authorization. Generally, each defines a distinct set of functionality for the server. ACIs define what operations can or cannot be performed by a user, group, or IP address for that particular ACL. You can change the default ACIs set up in the ACLs to change the privileges. You can also create new groups and assign privileges to those groups by adding ACI entries for that group in the ACLs. For complete details about creating users, assigning users to groups, creating groups, and changing ACIs and ACLs, see Chapter 9 "Authorization."

Default ACL Configuration

The configuration set up for the Online Certificate Status Manager gives the following privileges to members of the following groups:

• Administrators can perform any operations in the administrative interface which includes viewing configuration settings, changing configuration settings, adding or deleting plug-ins, creating or deleting instances or plug-ins, viewing all logs except for the signed audit log, if you have the signed audit feature set up. Administrators do not have any access to the agent services interface or any task performed there.
• Auditors can view the signed audit log, and can view configuration settings, but cannot perform any other operations on configuration settings and do not have any access to the agent services interface.
• Online Certificate Status Manager Agents can view configuration settings in the administrative interface, but cannot perform any other operations on the configuration settings, they can perform all operations for all tasks associated with the agent services interface.
• Trusted Managers all allowed to communicate with the Online Certificate Status Manager.

Managing Certificates and the Certificate Database

The signing certificate and SSL encryption certificate are created and installed during the installation of the Online Certificate Status Manager. See "OCSP Certificates" for more information about these certificates and the things you should consider before getting these certificates.

CMS contains a Certificate Wizard that allows you to create additional certificates, or to renew or replace a certificate for the Online Certificate Status Manager. See "Certificate Setup Wizard" for details of using the wizard and about renewing or replacing a subsystem certificate.

Trust Settings and CA Certificates

The trusted database also contains the CA certificates for those CAs that the subsystem trusts. If your subsystem has certificates from a CA or accepts certificates that are issued by a CA, it must have a copy of those CA certificates in the trusted database, and they must be configured as trusted, see "Changing the Trust Settings of a CA Certificate" and "Installing a New CA Certificate in the Certificate Database".

Certificate Chain

You also may need to install a certificate chain in the database to provide the chain of CAs to a trusted CA. You can install a certificate chain in the certificate database, see "Installing a CA Certificate Chain in the Certificate Database".

OCSP Certificates

Depending on who signed your Online Certificate Status Manager's SSL server certificate, you may need to perform the following actions to get that certificate recognized by the CA:

• If the Online Certificate Status Manager's SSL server certificate is signed by the CA that is publishing CRLs to the OCSP, you don't need to do anything.
• If the Online Certificate Status Manager's SSL server certificate is signed by the same root CA that signed the subordinate Certificate Manager's certificates, then you need to mark the root CA as a trusted CA in the subordinate Certificate Manager's certificate database.
• If the Online Certificate Status Manager's SSL server certificate is signed by a different root CA, then you need to import the root CA certificate into the subordinate Certificate Manager's certificate database and mark it as a trusted CA.

For general information about the OCSPs Certificates, see "OCSP Certificates".

Changing Ports and IP Addresses

You set up the ports for each of the interfaces when you install the Online Certificate Status Manager. You can change the ports that any of the interfaces listen on, and you can disable the HTTP (non-SSL) end-entity port if you will not use it. For information on changing ports, see "Ports". For information about the ports that are setup with an Online Certificate Status Manager, see "Interfaces".

You can also change the IP address for the CMS instance. You might do this if you have more than one IP address set up on your machine and want separate instances of CMS to use different IP addresses. You can do this during or after installation. See "Changing an IP Addresses" for details.

Changing Subsystem Security Setting

You can configure the security of each subsystem by changing the SSL version used by the subsystem and enabling or disabling ciphers, see "Configuring the Server's Security Preferences".

Changing Passwords or Storage Settings

Each subsystem stores passwords for its internal database, and for the tokens containing its keys and certificates. See "System Passwords" for information on how these passwords are stored.

Configuring Logs

Each subsystem creates a number of logs that detail various events and errors. Each subsystem also has the ability to create signed audit logs that create audit trails that can only be read by a user with auditor privileges. The log feature is configurable allowing you to change the settings for some of the logs. See "Logs" for complete information about the logs and details of the configuration options for logs.

Changing Internal Database Settings

You can change the configuration of the internal database after installation including restricting access to the internal database, see "The Internal Database" for information on doing this, and for information about viewing the internal database.

If the password changes for the user ID CMS uses to bind to this database, you need to update the password in the password cache. See "System Passwords".

Configuring Self Test

Each subsystem provides self tests that are run on start up and can also be run on demand. This feature is configurable, see "Self Tests" for complete information.

Setting Up Jobs

The jobs feature that allows you to send automated jobs is disabled after installation. The Online Certificate Status Manager contains the framework for jobs, but does not contain any prebuilt jobs. You can build jobs using the CMS SDK. For detailed information on setting up publishing, see Chapter 14 "Automated Jobs."

Identifying the CA to the OCSP Responder

Before you configure a Certificate Manager to publish CRLs to the Online Certificate Status Manager, you must identify the Certificate Manager to the Online Certificate Status Manager. You do this by storing the Certificate Manager's CA signing certificate in the internal database of the Online Certificate Status Manager. The Certificate Manager signs CRLs with the key pair associated with this certificate; the Online Certificate Status Manager verifies the signature against the stored certificate.

1. Get the Certificate Manager's CA signing certificate in base 64 encoded format. You should be able to get this from the end-entity interface of the CA that issued the certificate, or the end-entity interface of the Certificate Manager if the certificate is self-signed.
2. Go to the Online Certificate Status Manager's Agent interface. The URL is: https://<hostname>:<port>.

The Online Certificate Status Manager Agent Services interface appears.
 

3. In the left frame, click Add Certificate Authority.
4. In the form, paste the encoded CA signing certificate inside the text area labeled "Base 64 encoded certificate (including the header and footer)."
5. Click Add.

The certificate is added to the internal database of the Online Certificate Status Manager.
 

6. To verify that the certificate is added successfully, in the left frame, click List Certificate Authorities.

The resulting form should show information about the Certificate Manager (CA) you just added. Note the values assigned to the "This Update," "Next Update," and "Requests Served Since Startup" fields. All three fields should show a value of zero (0).
 

Verify Certificate Manager and Online Certificate Status Manager Connection

When you restart the Certificate Manager, it tries to connect to the Online Certificate Status Manager's end-entity SSL port. To verify that the Certificate Manager did indeed communicate with the Online Certificate Status Manager:

1. Enter the URL for the Online Certificate Status Manager's Agent interface. The URL is: https://<hostname>:<port>.

The Online Certificate Status Manager Agent Services interface appears.
 

2. In the left frame, click List Certificate Authorities.

The resulting form should show information about the Certificate Manager (CA) you configured to publish CRls to the Online Certificate Status Manager. Note the timestamp:
 

• The This Update and Next Update fields should now be updated with the appropriate timestamps, indicating that the Certificate Manager did communicate with the Online Certificate Status Manager.
• The Requests Served Since Startup field should show a value of zero (0), indicating that no OCSP-compliant client has queried the Online Certificate Status Manager yet for revocation status of a certificate.

Configure the Revocation Info Stores

The Online Certificate Status Manager stores each Certificate Manager's CRL in its internal database and uses it as the default CRL store for verifying the revocation status of certificates. You can also configure the Online Certificate Status Manager to use the CRL published to an LDAP directory, instead of the CRL in its internal database. For example, if you've configured Certificate Managers to publish CRLs to LDAP directories (see Chapter 16 "Publishing"), you can configure the Online Certificate Status Manager to use the CRLs published to these directories.

To configure the Online Certificate Status Manager to use the CRLs in its internal database or an LDAP directory for verifying revocation status of certificate:

1. Log in to the CMS window for the Online Certificate Status Manager (see Logging Into the CMS Console).
2. Select the Configuration tab.
3. In the navigation tree, select Online Certificate Status Manager, and then select Revocation Info Stores.

The right pane shows the two repositories the Online Certificate Status Manager can use; by default, it uses the CRL in its internal database.
 

4. Select the appropriate option:
• If you want to configure the Online Certificate Status Manager to use the CRLs in its internal database, select defStore and click Edit/View.
• If you want to configure the Online Certificate Status Manager to use the CRLs in one or more directories, first click Set Default to enable the ldapStore option, select ldapStore, and click Edit/View. (Clicking Set Default toggles the selection between the two repositories.)

The Revocation Info Store Editor for the selected store appears.
 

5. Fill in the appropriate values.
• If you selected defStore, fill in values as below:

notFoundAsGood. A certificate's status can typically be indicated by three possible OCSP responses, namely GOOD, REVOKED, and UNKNOWN. Select this option if you want the Online Certificate Status Manager to return an OCSP response of GOOD if the certificate in question cannot be found in any of the CRLs. If you deselect the option, the response will be UNKNOWN, which when encountered by an OCSP-compliant client results in an error message.
 

includeNextUpdate. The Online Certificate Status Manager can include the time stamp of next CRL update—a future update time for the CRL or the revocation information—in the OCSP response that it sends to OCSP-compliant clients. (According to the OCSP protocol, it is optional to include the time stamp of next CRL update in an OCSP response.) Select this option if you want the OCSP response to contain information about the next CRL update. Leave the option deselected if you don't want the OCSP response to contain this information.
 

• If you selected ldapStore, fill in values as below:

numConns. Type the total number of LDAP directories the Online Certificate Status Manager should check. By default, this is set to 0. If you change the value to a positive integer, for example 1, 2, or 3, you will see that many sets of host, port, baseDN, and refreshInSec fields. (Change the value, click OK, and reopen the window to see the updated fields.)
 

host<n>. Type the fully-qualified DNS hostname of the LDAP directory. The name must be in the <machine_name>.<your_domain>.<domain> form. For example, corpDir1.example.com.
 

port<n>. Type the nonSSL port of the LDAP directory. For example, 389.
 

baseDN<n>. Type the DN to start searching for the CRL. For example, O=example.com.
 

refreshInSec<n>. Type how often the connection is refreshed. The default is 86400 seconds (that is, refresh every day).
 

caCertAttr. Leave the default value, cACertificate;binary, as it is. (It's the attribute to which the Certificate Manager publishes its CA signing certificate.)
 

crlAttr. Leave the default value, certificateRevocationList;binary, as it is. (It's the attribute to which the Certificate Manager publishes CRLs.)
 

notFoundAsGood. A certificate's status can typically be indicated by three possible OCSP responses, namely GOOD, REVOKED, and UNKNOWN. Select this option if you want the Online Certificate Status Manager to return an OCSP response of GOOD if the certificate in question cannot be found in any of the CRLs. If you deselect the option, the response will be UNKNOWN, which when encountered by Netscape Personal Security Manager (an OCSP-compliant client) results in an error message.
 

includeNextUpdate. The Online Certificate Status Manager can include the time stamp of next CRL update—a future update time for the CRL or the revocation information—in the OCSP response that it sends to OCSP-compliant clients. (According to the OCSP protocol, it is optional to include the time stamp of next CRL update in an OCSP response.) Select this option if you want the OCSP response to contain information about the next CRL update. Leave the option deselected if you don't want the OCSP response to contain this information.
 

6. Click OK.

You're returned to the Revocation Store Info Management tab
 

7. Click Refresh.

Testing Your OCSP Setup

---

To test whether the Certificate Manager can service OCSP requests properly, follow these steps:

1. Turn On Revocation Checking in your browser or client.
2. Request a certificate from the CA that has been enabled for OCSP services.
3. Approve the request.
4. Download the certificate to the browser or client.
5. Make sure the CA is trusted by the browser or client.
6. Check the Status of Certificate Manager's OCSP Service (internal OCSP service).

Go to the agent services interface for the Certificate Manager and then go to the OCSP Services page.
 

The Certificate Manager's Agent services interface contains a form that enables you to check the Certificate Manager's OCSP-service status, such as how many request its received and so on. Click OCSP Services in the left frame in the agent services interface.
 

7. Check the Status of Online Certificate Status Manager (stand-alone OCSP service).

Go to the agent services interface for the Online Certificate Status Manager and then go to the List Certificate Authorities page found in the left frame.
 

The resulting form should show information about the Certificate Manager (CA) you configured to publish CRls to the Online Certificate Status Manager. The page also summarizes the Online Certificate Status Manager's activity since it was last started.
 

8. Revoke the certificate
9. Verify the certificate in the browser or client. Once verified, you should see that the certificate has been revoked.
10. Check the Certificate Manager's OCSP Service Status (internal OCSP) again

Check the Certificate Manager's OCSP-service status again to verify that these things happened:
 

• The browser sent an OCSP query to the Certificate Manager (this response was initiated when you clicked the View button).
• The Certificate Manager sent an OCSP response to the browser.
• The browser used that response to validate the certificate and informed you of its status (that the certificate could not be verified).
11. Check the Online Certificate Status Manager Status (stand-along OCSP service) Again

Check the Online Certificate Status Manager status again to verify that these things happened:
 

• The Certificate Manager published the CRL (the revoked certificate) to the Online Certificate Status Manager.
• The browser sent an OCSP response to the Online Certificate Status Manager (this response was initiated when you clicked the View button).
• The Online Certificate Status Manager sent an OCSP response to the browser.

The browser used that response to validate the certificate and informed you of its status (that the certificate could not be verified)

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

Last Updated November 23, 2004