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

Chapter 3   Certificate Manager


The Certificate Manager subsystem provides the services of a Certificate Authority (CA) in the PKI. It can issue, renew, and revoke certificates; create and issue CRLs; and publish certificates and CRLs.

This chapter discusses the Certificate Manager subsystem. It provides an overview of the subsystem including the decisions you need to make before installing the subsystem, complete installation instructions, an overview of the Certificate Manager processes including information on configuring those processes, information about FBCA, and details on configuring a cloned CA.

This chapter contains the following sections:

Certificate Manager Deployment Considerations

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

Self-Signed Root vs. Subordinate CA

A Certificate Manager can be set up as a self-signing root CA. You set up a self-signing root CA by choosing this option when you install. A self-signing root CA issues and signs its own certificates. The subsystems are then issued certificates by this self-signing CA.

A Certificate Manager can be setup as a subordinate CA. It can either be subordinate to a public CA that signs its certificates, or to another CMS CA that signs its certificates. A subordinate CA is restricted in the types of certificates it can issue, and what the content of those certificates are by the contents and settings of the CA signing certificate issued to it.

For the purposes of an initial pilot, it is easiest to make the CA a self-signed root, so that you won't need to apply to a third party and wait for the certificate to be issued. Before deploying a full-blown PKI, however, you will need to consider this question carefully.

Understanding Certificate Manager Subordination

A Certificate Manager (or CA) is subordinate to another CA because its CA signing certificate, the certificate that allows it to issue certificates, is issued by another CA. The CA that issued the subordinate CA signing certificate controls the CA through the contents of the CA signing certificate. The CA can constrain the subordinate CA through the kinds of certificates that it can issue, the extensions that it is allowed to include in certificates, the number of level of subordinate CAs the subordinate CA can create, and the validity period of certificates it can issue, as well as the validity period of the subordinate CAs signing certificate.

Although a subordinate CA can create certificates that violate these constraints, a client authenticating a certificate that violates those constraints will not accept that certificate.

Subordination to a Public CA

If you want your CA to chain up to a third-party public CA, you must carefully consider the restrictions that public CAs place on the kinds of certificates your CA can issue and the nature of the certificate chain. For example, a CA that chains up to a third-party CA might be restricted to issuing only Secure Multipurpose Internet Mail Extensions (S/MIME) and SSL client authentication certificates; but not SSL server certificates. In addition, a CA that chains up to a third-party CA might not be allowed to have any subordinate CAs and might have to obey certain restrictions on its use of certificate extensions. These and other restrictions may be acceptable for some PKI deployments but not for others.

One benefit of chaining up to a public CA is that the third party is responsible for getting the root CA certificate into the browser or other client software. This can be a major advantage if you are deploying an extranet that involves certificates used by different companies whose browsers you cannot control. Alternatively, if you create your own CA hierarchy from scratch, you are responsible for getting your root certificate into all the browsers used with the certificates you issue. If you are using Netscape Communicator as your client, you can accomplish this task within an intranet by using tools such as Mission Control Desktop or with the aid of Personal Security Manager, but extranet deployments can be more complicated.

Subordination to Another CMS CA

If you set up a CA using CMS that has subordinate CAs, you control the subordinate CAs by setting policies that control the contents of the CA signing certificate issued. A subordinate CA issues certificates evaluating its own authentication, policy, and certificate profile configuration, it is completely unaware of its parents set up for these configurations.

A Certificate Manager cannot issue a certificate that has a validity period longer than the validity period of the CAs' CA signing certificate. Any requests that are for a period longer than this will result in certificates issued only to the validity period of the CAs' CA signing certificate.

Cloned CA

A Certificate Manager can also be cloned so that more than one CA shares the same set of keys and certificates allowing more than one CA issue certificates with the same issuer name and keys. Each clone CA issues a different set of serial numbers. Where the relationship between a self-signed CA and its subordinates is hierarchical, a CA and its clones function together, effectively forming a single Certificate Manager with failover support (and, potentially, load balancing on the front end). For details about a CA, see "Cloning a CA".

Certificate Manager Certificates

When you install the Certificate Manager, the keys for the CA signing certificate, SSL server certificate, and OCSP signing certificate are created and a certificate request is made for the CA signing certificate and the SSL server certificate. The OCSP signing certificate is created by the CA itself.

You submit this request either as a self-signing request to the CA itself which will then issue the certificates, this is how you create a self-signing root 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.

About the CA Key Pairs and Certificates

This section describes the key pairs and certificates associated with the Certificate Manager.

CA Signing Key Pair and Certificate

Every Certificate Manager you install has a Certificate Manager CA signing certificate, whose public key corresponds to the private key the Certificate Manager uses to sign the X.509 certificates and CRLs it issues. This certificate is created and installed when you install the Certificate Manager. The default nickname for the certificate is caSigningCert cert-<instance_id>, where <instance_id> identifies the CMS instance in which the Certificate Manager is installed, and the default validity period for the certificate is two years.

The subject name of the CA signing certificate reflects the name of your certificate authority (CA) as specified during the installation. All certificates signed or issued by the Certificate Manager include this name to identify the issuer of the certificate.

The Certificate Manager's status as a root or subordinate CA is determined by whether its CA signing certificate is self-signed or is signed by another CA.

OCSP Signing Key Pair and Certificate

Irrespective of whether you chose to enable the OCSP service feature, the Installation Wizard transparently generates a key pair and a corresponding certificate identified as the OCSP signing certificate.

The wizard uses the key type, key size, key algorithm, and validity period you provided for the CA signing key pair to generate the OCSP signing key pair. The subject name of the OCSP signing certificate is in the form CN=OCSP cert-<cms_instance_id>, and it contains extensions, such as OCSPSigning and OCSPNoCheck, required for signing OCSP responses.

The default nickname for the OCSP signing certificate is
ocspSigningCert cert-<instance_id>, where <instance_id> identifies the CMS instance in which the Certificate Manager is installed.

The Certificate Manager uses the private key (that corresponds to the public key used to generate the OCSP signing certificate) to sign the OCSP responses it sends to the OCSP-compliant clients when queried about the revocation status of certificates.

SSL Server Key Pair and Certificate

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

The Certificate 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 the Certificate Manager itself, another internally deployed CA, or a public CA.

By default, the Certificate Manager uses a single SSL server certificate for authentication purposes. However, you can request and install additional SSL server certificates for the Certificate Manager. For example, you can configure the Certificate Manager to use separate server certificates for authenticating to the End-Entity Services interface and Agent Services interface. See Managing Certificates and the Certificate Database for more details.

If you configure the Certificate Manager for SSL-enabled communication with a publishing directory, the Certificate Manager also uses its SSL server certificate for SSL client authentication to the publishing directory. This is the default configuration. You can configure the Certificate Manager to use an alternate certificate for this purpose. See Managing Certificates and the Certificate Database for more details.

If you configure the Certificate Manager to function as a trusted manager to a Data Recovery Manager, the Certificate Manager also uses its SSL server certificate for SSL client authentication to the Data Recovery Manager. For details on trusted managers, see Trusted Managers. You can also configure the Certificate Manager to use an alternate certificate for this purpose. See Managing Certificates and the Certificate Database for more details.

Certificate Considerations

This section explains some of the decisions you need to make about the certificates you get for the Certificate Manager when you install the subsystem.

CA's Distinguished Name

The core elements of a CA consist of a signing unit and the Certificate Manager's own identity. The signing unit digitally signs certificates requested by end-entities that use a specified enrollment process to establish their identities. Regardless of how related Registration Managers or Data Recovery Managers are configured, any Certificate Manager must have its own distinguished name (DN), which is listed in every certificate it issues.

Like any other X.509 version 3 certificate, a CA certificate binds a DN to a public key. A DN is a series of name-value pairs that in combination uniquely identify an entity. For example, the following DN might be used to identify a hypothetical Certificate Manager for the Engineering department of a corporation named Example Corporation: cn=demoCA, o=Example Corporation, ou=Engineering, c=US

Many combinations of name-value pairs are possible for the Certificate Manager's DN. The DN must be unique and readily identifiable, since any end entity can examine it. For more information about DNs, see Managing Servers with Netscape Console.

CA Signing Certificate's Validity Period

Every certificate, including a Certificate Manager signing certificate, must have a validity period. CMS does not restrict the validity period you can specify. In general it's a good idea to specify as long a validity period as possible, depending on your plans for certificate renewal, the place of the CA in the certificate hierarchy, and the requirements of any public CAs that you may want to include in your PKI.

Serial Number Ranges for the CA

You can designate the starting and ending serial numbers that a CA can issue during the configure of the CA. This is especially useful when you are installing cloned CAs. Each cloned CA is given a specific range of serial numbers that it can issue. In this way, none of the cloned CAs can issue the same serial number.

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.

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, see the following 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. 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.

Certificate Manager Interfaces

When you install a Certificate 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:

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.

Internal Database

Each Certificate Manager instance contains an internal database that stores certificates, certificate requests and the like.

During installation, you set up this database by either choosing to create a new database, or use an existing database, providing user IDs and passwords for special users of the database, and the port the database will listen to requests on. 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 is configured for storing CMS data.

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, SmartCard. For installation instructions, see External Token.

Installing a Certificate Manager

You install the subsystems by installing the CMS software on each host in which you will install a subsystem, and then creating an instance of CMS in that installation for each subsystem you want to configure on that host. CMS provides an Installation Wizard that allows you to choose which subsystem you are installing in a particular instance, and allows you to make some configuration choices for the subsystem, and get and install the certificates used by the subsystem. Once the Certificate Manager is installed, it is set up with a default set of configuration settings. You can change the default settings to meet the needs of your PKI.

Installing a Certificate Manager as a Root CA

To configure the Certificate Manager as a root CA:

  1. Log into Netscape Console as the administrator, see Netscape Console.
  2. Select the CMS instance and then either click Open, or double click this instance.
    3. The Installation Wizard launches.
     
  3. Installation Wizard Introduction. Click Next to continue.
  4. Logon Token. Choose 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.
    6. Click Next to continue. The wizard sets up the new internal database, which takes some time.
     
  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.
    7. 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, and trusted manager roles.
     
    If you select this, allowing users to assume multiple roles, the administrator you set up in this window will be added to the agents group. This administrator will be both an administrator and an agent.
     
    Click Next to continue.
     
  7. Subsystems. Choose the subsystem you want to install.
    8. Select Certificate Manager.
     
    Click Next to continue.
     
  8. Remote Data Recovery Manager. Select the appropriate options:
    9. Click Next to continue.
     
  9. CA's Serial Number Range. Specify the range for the serial numbers for the certificates that this CA will issue. In the "Starting serial number" field, type the lowest serial number the CA should assign to a certificate. If you plan to only use one CA server, you can leave the "Ending serial number" field blank to indicate no upper limit. If you plan to clone the CA to distribute load, you must specify an upper limit. (For cloned CAs, you must make sure that the range of serial numbers does not overlap with any other CA server.)
    10. Click Next to continue.
     
  10. Internal OCSP Services. Select to enable the internal OCSP services.
    11. See "Setting Up a Certificate Manager with OCSP Service" for more information.
     
    Click Next to continue.
     
  11. Network Configuration. Type the port numbers for the ports used by this instance, or accept the defaults.
    12. See "Certificate Manager Interfaces" for more information.
     
    Click Next to continue.
     
  12. CA Signing Certificate. Select the "Create self-signed CA certificate" option.
    13. Click Next to continue.
     
  13. Key-Pair Information for Certificate Manager CA Signing Certificate.
    14. Click Next to continue.
     
  14. Message Digest Algorithm. Select the algorithm to use for computing the certificate signature. The choices are: MD2, MD5, or SHA-1.
    15. Click Next to continue.
     
  15. Subject Name for Certificate Manager CA Signing Certificate. Type values for the subject DN components; these values identify the root CA signing certificate.
    16. A DN is a series of name-value pairs that in combination uniquely identify an entity. The subject DN identifies the CA signing certificate. You are not required to enter all the values.
     
    See CA's Distinguished Name for more information.
     
    Click Next to continue.
     
  16. Validity Period for Certificate Manager CA Signing Certificate. Select the validity period for the CA signing certificate. The default validity is two years. The validity period determines how soon you will have to renew the certificate, which can be a complex procedure.
    17. See CA Signing Certificate's Validity Period for more information.
     
    Click Next to continue.
     
  17. Certificate Extensions for Certificate Manager CA Signing 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.
    18. 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 the CMS Command-Line Tools Guide.
     
    For more information about extensions, see Appendix G "Certificate and CRL Extensions."
     
    Click Next to continue.
     
  18. Certificate Manager CA Signing Certificate Creation. Click Next to generate and install the certificate.
  19. SSL Server Certificate. Select the "Sign SSL certificate with my CA signing certificate" option. This option enables the wizard to generate an SSL Server Certificate signed with the local CA signing certificate, the root Certificate Manager's CA signing certificate you just created.
    20. Click Next to continue.
     
  20. Key-Pair Information for SSL Server Certificate.
    21. See Signing Key Type and Length for more information.
     
    Click Next to continue.
     
  21. Message Digest Algorithm. Select the algorithm to use for computing the certificate signature. The choices are: SHA-1, MD2, or MD5.
    22. Click Next to continue.
     
  22. Subject Name for SSL Server Certificate. Type the values for the subject DN components; these values identify the root CA's SSL server certificate. The CN must be the fully-qualified host name of the machine on which you're installing the Certificate Manager.
    23. Click Next to continue.
     
  23. Validity Period for SSL Server Certificate. Select the validity period for the SSL server certificate. The validity period determines how soon you will have to renew the certificate.
    24. Click Next to continue.
     
  24. 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 (see Step 17).
    25. Click Next to continue.
     
  25. SSL Server Certificate Creation. This informational screen tells you that the configuration wizard has all the required information to generate a key pair and its corresponding certificate.
    26. Click Next to generate the certificate.
     
  26. Single Sign-on Summary. Check the summary and select whether to retain or delete the password.conf file. For details, see Token Password Storage.
    27. Click Next to continue.
     
  27. Configuration Status. This screen should indicate that your configuration has been successful.
    28. Click Done to exit the Installation Wizard.
     
  28. You now need to create the first agent user for the Certificate Manager. See "Agent Certificates" for details.

Installing a Certificate Manager as a Subordinate CA

To install the Certificate Manager as a subordinate CA:

  1. Log into Netscape Console as the administrator, see Netscape Console.
    2. The main window of Netscape Console appears.
     
  2. Select the CMS instance and then either click Open, or double click this instance.
    3. 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.
    6. 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.
    7. 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, and trusted manager roles.
     
    If you select this, allowing users to assume multiple roles, the administrator you set up in this window will be added to the agents group. This administrator will be both an administrator and an agent.
     
    Click Next to continue.
     
  7. Subsystems. Choose a subsystem you want to install.
    8. Select Certificate Manager.
     
    Click Next to continue.
     
  8. Remote Data Recovery Manager. Select the appropriate options:
    9. Click Next to continue.
     
  9. CA's serial number range. Specify range for the serial numbers for the certificates that this CA will issue. In the "Starting serial number" field, type the lowest serial number the CA should assign to a certificate. If you only use one CA server, you can leave the "Ending serial number" field blank to indicate no upper limit. If you plan to clone the CA to distribute load, you must specify an upper limit. (For cloned CAs, you must make sure that the range of serial numbers does not overlap with any other CA server.)
    10. Click Next to continue.
     
  10. Internal OCSP Services. Select to enable the internal OCSP services.
    11. See "Setting Up a Certificate Manager with OCSP Service" for more information.
     
  11. Network Configuration. Type the port numbers for the ports to be used by the CMS instance.
    12. See "Certificate Manager Interfaces" for more information.
     
    Click Next to continue.
     
  12. CA Signing Certificate. Select the "Create subordinate CA certificate request" option.
    13. Click Next to continue.
     
  13. Key-Pair Information for Certificate Manager CA signing certificate.
    14. See Signing Key Type and Length for more information.
     
    Click Next to continue.
     
  14. Message Digest Algorithm. Select the algorithm to use for computing the certificate signature. The choices are: MD2, MD5, or SHA-1.
    15. Click Next to continue.
     
  15. Subject Name for Certificate Manager CA Signing Certificate. Type values for the subject DN components; these values identify the subordinate CA signing certificate.
    16. A DN is a series of name-value pairs that in combination uniquely identify an entity. The subject DN identifies the CA signing certificate. You are not required to enter all the values.
     
    See CA's Distinguished Name for more information.
     
    Click Next to continue.
     
  16. Validity Period for Certificate Manager CA Signing Certificate. Select the validity period for the subordinate CA signing certificate. The default validity is two years. The validity period determines how soon you will have to renew the certificate, which can be a complex procedure.
    17. See CA Signing Certificate's Validity Period for more information.
     
    Click Next to continue.
     
  17. Certificate Extensions for Certificate Manager CA Signing 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.
    18. 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 about using the ExtJoiner program, see Chapter 5, "Extension Joiner Tool" of CMS Command-Line Tools Guide.
     
    For more information about extensions, see Appendix G "Certificate and CRL Extensions."
     
    Click Next to continue.
     
  18. Certificate Manager CA Signing Certificate 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.
    19. Click Next to generate the request. The wizard creates a certificate request that you must submit to another CA.
     
  19. Submission of Request. Select whether you want to submit the request manually or send the request to a remote Certificate Manager automatically.
    20. Click Next when you are ready to proceed.
     
  20. CA Signing Certificate Installation. Depending on whether you have the certificate ready for pasting into the Installation Wizard screen, click Yes or No.
    21. Click Next to continue.
     
  21. Location of Certificate. Specify the location of the certificate. You can use any of these options:
    22. Click Next to continue.
     
  22. Certificate Details. This is an informational screen that shows the certificate so you can inspect its contents. Notice the nickname assigned to the certificate and verify that you're installing the correct certificate.
    23. Click Next to continue.
     
  23. Import Certificate Chain. This screen appears only if you need to import the CA certificate chain. If the CA that issued the certificate is a Certificate Manager, follow these steps:
    1. Go to the end-entity URL for the Certificate Manager that issued the subordinate CA's signing certificate.
    2. Select the Retrieval tab, and then choose Import CA Certificate Chain.
    3. Select the "Display the CA certificate chain in PKCS#7 for importing into a server" option, and then click Submit.
    4. Copy the certificate chain to the clipboard.
    5. Return to the Installation Wizard.
    6. Paste the certificate chain into the text box.
    Click Next to continue.
     
  24. SSL Server Certificate. Select the appropriate option:
    25. Click Next to continue.
     
  25. Key-Pair Information for SSL Server Certificate.
    26. See Signing Key Type and Length for more information.
     
    Click Next to continue.
     
  26. Message Digest Algorithm. Select the algorithm to use for computing the certificate signature. The choices are: SHA-1, MD2, or MD5.
    27. Click Next to continue.
     
  27. Subject Name for SSL Server Certificate. Type the values for the subject DN components; these values identify the subordinate CA's SSL server certificate. The CN must be the fully-qualified host name of the machine on which you're installing the Certificate Manager.
    28. Click Next to continue.
     
  28. 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. (For details, see Step 17 of this section.)
    29. Click Next to continue.
     
  29. 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 screens, if you chose to generate a certificate request and 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.
    30. Click Next to generate the certificate or the request:
     
  30. Submission of Request. Select whether you want to submit the request manually or send the request automatically to a remote Certificate Manager.
    31. Click Next when you are ready to proceed to the next screen.
     
  31. SSL Server Certificate Installation. Depending on whether you have the certificate ready for pasting into the Installation Wizard screen, click Yes or No.
    32. Click Next to continue.
     
  32. Location of Certificate. Specify the location of the certificate. You can use any of these options:
    33. Click Next to continue.
     
  33. 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.
    34. Click Next to continue.
     
  34. Import Certificate Chain. This screen appears only if you need to import the CA certificate chain. If the CA that issued the certificate is a Certificate Manager, follow these steps:
    1. Go to the end-entity URL for the remote Certificate Manager that issued the SSL server certificate.
    2. Select the Retrieval tab, and then in the left-hand frame, click Import CA Certificate Chain.
    3. Select the "Display the CA certificate chain in PKCS#7 for importing into a server" option, and then click Submit.
    4. In the resulting form, locate the CA certificate chain, in its base-64 encoded format, to the clipboard.
    5. Return to the Installation Wizard.
    6. Paste the certificate chain into the text box.
    Click Next to continue.
     
  35. Single Sign-on Summary. Check the summary and select whether to retain or delete the password.conf file. For details, see Token Password Storage.
    36. Click Next to continue.
     
  36. Configuration Status. This screen should indicate that your configuration has been successful.
    37. Click Done to exit the Installation Wizard.
     
  37. You now need to create the first agent user for the Certificate Manager. See "Agent Certificates" for details.

Configuring the Certificate Manager

This section lists the areas that you can configure for the Certificate Manager, gives a description of that area, and points you to specific information on configuring that set of features.

Adding Users

Once the Certificate Manager is installed, you need to add users and assign them to the administrator, agent, or auditor roles. If you selected the option to have the administrator created during installation also act as an agent, then the administrator is your first agent. If you did not, you need to create an agent user who can access the agent services interface. See Chapter 9 "Authorization" for details on adding users and assigning them to groups.

Configuring Authorization

Each subsystem has a set of predefined roles that are assigned a default set of privileges. You create users in the CMS database and then assign them to a group to give them the privileges of that group. The privileges assigned to a group 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 of a user, group, or IP address. 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 Certificate Manager gives the following privileges to members of the following groups:

Managing Certificates and the Certificate Database

The CA signing certificate, SSL encryption certificate, and OCSP signing certificate are created and installed during the installation of the Certificate Manager. See "Certificate Manager 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 Certificate 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 may also need to install a certificate chain in the database to provide the chain of CAs to a trusted CA. See "Installing a CA Certificate Chain in the Certificate Database".

Getting a CRL Signing Key Pair and Certificate

A Certificate Manager uses the key pair corresponding to the CA signing certificate for signing certificates and certificate revocation lists (CRLs).

If you want a Certificate Manager to use a separate key pair for signing the CRLs it generates, you can do so after installation. Note that a Certificate Manager's CRL signing certificate must be signed or issued by itself; make sure you submit the request to the Certificate Manager itself.

To enable a Certificate Manager to sign CRLs with a separate key pair:

  1. Request and install a CRL signing certificate for the Certificate Manager. To do this, you may use either of these options:
    2. To request and install a CRL signing certificate for a Certificate Manager using its Certificate Setup Wizard, follow these instructions:
     
    1. Log in to the CMS console (see Logging Into the CMS Console).
    2. Select the Configuration tab, and then select the Encryption tab.
    3. Click Certificate Setup Wizard to launch the wizard.
    4. Select the option to request a certificate and then follow the on-screen prompts to generate a certificate request for the CRL signing certificate—in the Certificate Selection window, select Other and specify caCrlSigning as the certificate type in the associated text field.
    5. Once you have the certificate request ready, submit it to the Certificate Manager so that it can issue a certificate—in the request submission screen of the wizard, use the auto-submission feature by entering the Certificate Manager's hostname and port number so that the request gets added to the Certificate Manager's agent queue.
    6. Log in to the Agent Services interface, check the request for required extensions. For example, the CRL signing certificate must contain the Key Usage extension with the crlSigning bit set. (By default, the Certificate Manager's policy is configured to add the Key Usage extension with correct bits to the CRL signing certificate; see the policy rule named CRLSignCertKeyUsageExt, which is an instance of KeyUsageExt plug-in.)
    7. Approve the request.
    8. Once you have the CRL signing certificate ready, restart the wizard and install the certificate in the Certificate Manager's database.
  2. Stop the Certificate Manager.
  3. Update the Certificate Manager's configuration to recognize the new key pair and certificate.
    1. In the Certificate Manager host machine, go to this directory: <server_root>/cert-<instance_id>/config
    2. Open the CMS.cfg file in a text editor.
    3. Add the following lines to the configuration file:

      4. ca.crl_signing.cacertnickname=<nickname> cert-<instance_id>
      ca.crl_signing.defaultSigningAlgorithm=<signing_algorithm>
      ca.crl_signing.tokenname=<token_name>

      Where:

      nickname

      Is the name assigned to the CRL signing certificate.

      instance_id

      Is the name assigned to the Certificate Manager instance.

      signing_algorithm

      Is MD5withRSA, MD2withRSA, or SHA1withRSA, if the key type is RSA, or SHA1withDSA, if the key type is DSA.

      token_name

      Is the name of the token used for generating the key pair and the certificate. If you used the internal/software token, use Internal Key Storage Token as the value.


       
      For example, your edited entries might look like this:
       

      ca.crl_signing.cacertnickname=crlSigningCert cert-demoCA
      ca.crl_signing.defaultSigningAlgorithm=MD5withRSA
      ca.crl_signing.tokenname=Internal Key Storage Token

    4. Save your changes and close the file.
  4. Restart the Certificate Manager. Now the Certificate Manager is ready to use the CRL signing certificate to sign the CRLs it generates.

Getting Additional SSL Server Certificates

The Certificate Manager uses its SSL server certificate to do SSL server-side authentication to the following:

By default, the Certificate Manager uses a single SSL server certificate for authentication purposes. However, you can request and install additional SSL server certificates for the Certificate Manager. For example, you can configure the Certificate Manager to use separate server certificates for authenticating to the End-Entity Services interface and Agent Services interface. For instructions, see Configuring the Server to Use Separate SSL Server Certificates.

If you configure the Certificate Manager for SSL-enabled communication with a publishing directory, the Certificate Manager also uses its SSL server certificate for SSL client authentication to the publishing directory. This is the default configuration. You can configure the Certificate Manager to use an alternate certificate for this purpose; see Getting an SSL Client Certificate for a Subsystem.

If you configure the Certificate Manager to function as a trusted manager to a Data Recovery Manager, the Certificate Manager also uses its SSL server certificate for SSL client authentication to the Data Recovery Manager. For details on trusted managers, see Trusted Managers. You can also configure the Certificate Manager to use an alternate certificate for this purpose; see Getting an SSL Client Certificate for a Subsystem.

CA Certificate Renewal or Reissuance

When a CA signing certificate expires, all certificates signed with the CA's corresponding signing key become invalid. End entities use information in the CA certificate to verify the certificate's authenticity. If the CA certificate itself has expired, applications cannot chain the certificate to a trusted CA.

There are two ways of dealing with CA certificate expiration:

There are advantages and disadvantages to each approach. Correct use of extensions, for example the authorityKeyIdentifier extension, can also affect the transition from an old CA certificate to a new one. You should begin planning for CA renewal or reissuance before you install any CMS managers; consider any ramifications your planned procedures may have for extensions, policies, and other aspects of your initial PKI deployment.

Changing Ports and IP Addresses

You set up the ports for each of the interfaces when you install the Certificate Manager. You can change the ports that any of the interfaces listen on, and you can remove 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 a Certificate Manager, see "Certificate Manager 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 cannot do this during installation; you can only change this setting 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 a Mail Server

If the subsystem will be sending out email notifications, you can configure the subsystem to use a mail server, see "Mail Server".

Changing the Certificate Issuance Rules

You can change some of the rules about certificate issuance that were either determined during installation, or are the system defaults. These include:

To change the certificate issuance rules:

  1. In the CMS window, select the Configuration tab.
  2. In the navigation tree, select Certificate Manager.
    3. The General Setting tab appears.
     
  3. Change the following fields in this tab:
    4. Override validity nesting requirement. Specifies if the Certificate Manager can issue certificates with validity periods beyond that of its CA signing certificate.
     
    If deselected and the Certificate Manager (CA) receives a request with validity period extending beyond that of its CA signing certificate, it automatically truncates the validity period to end on the day the CA signing certificate expires.
     
    Validity periods of certificates during enrollment is determined by the ValidityConstraints plug-in module, "ValidityConstraints". Similarly, validity periods of certificates during renewal is determined by the RenewalValidityConstraints plug-in module, see "RenewalValidityConstraints".
     
    Certificate Serial Number. Specifies the serial number range for certificates issued by this Certificate Manager. The server assigns the serial number you enter in the "Next serial number" to the next certificate it issues and the number you enter in the "Ending serial number" to the last certificate it issues.
     
    The serial number range enables you to deploy multiple CAs, balancing the number of certificates each CA issues. Note that the combination of an issuer name and a serial number uniquely identifies a certificate. To ensure that two distinct certificates issued by the same authority doesn't contain the same serial number, make sure the serial number range does not overlap among cloned CAs.
     
    Also note that when a CA exhausts all its serial numbers, you can revive it by changing the values in the "Next serial number" and "Ending serial number" fields, followed by restarting the Certificate Manager.
     
    Default Signing Algorithm section. Specifies the signing algorithm the Certificate Manager should use for signing certificates. The choices are "MD2 with RSA", "MD5 with RSA", and "SHA1 with RSA", if the CA's signing key type is RSA and "SHA1 with DSA", if the CA's signing key type is DSA.
     
    Note that the signing algorithm specified in the Certificate Manager's policy configuration or certificate profile configuration overrides the algorithm you select here.
     
  4. To save your changes, click Save.

Setting Up Authentication

The first step in configuring enrollment is setting up authentication. You can set up more than one type of authentication. Each type you set up must be associated with a particular form in the interface. If you are using the certificate profile feature for enrollments, the forms are dynamically generated with the content being determined by the inputs you set for a particular certificate profile. You can even set up the same method of authentication and associated more than one form with it. You might do this if you wanted to change other aspects of the enrollment.

For example, you might want to create an automated enrollment that requires LDAP authentication. You have two classes of employees, permanent and temporary. You want to issue both classes of employees certificates using LDAP authentication, but you want to issue each of these classes certificates with different validity periods and different extensions. You can create two different forms, both using LDAP authentication, but each having different policies associated with the form.

You can configure the enrollment method to be agent-approved or automated.

The agent-approved enrollment and CMC enroll methods are enabled and configured when you install the Certificate Manager. In order to enable and configure one of the automated enrollment methods, you need to enable and configure that authentication instance. You can also provide certificate based authentication for either agent-approved or automated enrollments. For detailed information on setting up authentication, see Chapter 10 "Authentication."

Agent-Approved Enrollment

The Certificate Manager is enabled by default for agent-approved enrollment. The agent-approved enrollment forms are used to enroll end entities that require manual approval and whose requests have been sent to the agent services interface for processing. Agent-approved certificate profile enrollments are also sent to the agent services interface for processing.

Automated Enrollment

You set up enrollment by configuring instances of the authentication plug-ins. The plug-ins allow you to set up the kind of authentication you will use for authentication. All of the authentication plug-ins also enable an automated enrollment when they are enabled. You can enable one of the authentication plug-ins, and configure it to be able to authenticate.

Once you have set up an authentication instance, end entities use a form associated with this method when enrolling. You must provide the necessary fields to collect the information required for the method of authentication in the form, otherwise you can customize the form as you like. If you are using the certificate profile feature, the forms are dynamically generated using the inputs you specify for a certificate profile.

The authentication methods that you can configure are:

Configuring Policies

The Policy feature is a set of plug-ins that you create instances of and then configure. These instances define certificate content and the values for that content and constraints for the content that can either be associated with all certificates, or with a subset of certificates defined using predicates. When a non-certificate profile enrollment request is processed, it is evaluated against all policies that are applicable to this type of request. Any policy that has no predicate is evaluated against all certificate requests. Those with predicates are evaluated against certificates requests that match the predicate value of the policy. The predicate value can be a certificate type, like a CA certificate or an SSL signing certificate, in which case, all requests for that type of certificate are evaluated by the policy. The predicate value can be some other evaluator that can be matched in the request. You can use hidden values in the request form to match predicate values.

When using the policy feature for enrollment, you must take care to associate a form with all of the policies you want to be evaluated for this certificate request.

Some of the policies can be configured to collect other information about an end entity from an LDAP directory and place that information in the certificate. A default set of policies is created. Some of these are enabled and some are disabled. You need to configure the policy feature by configuring the existing policies, deleting unwanted policies, and creating needed policies that are not created by default.

See also the following for information on certificate profiles, which replace the policies functionaly in current and future releases of CMS.

For detailed information, see Chapter 12 "Policies."

Configuring Certificate Profiles

The Certificate Profile feature uses instances of certificate profile plug-ins that can be configured to issue a type of certificate. The certificate profile contains defaults that specify the contents and the value of that content for this type of certificate, constraints that constrain the content of this type of certificate, associate the certificate profile with a set up authentication method, and define the contents of the enrollment page and the output page when an automated authentication method is used.

The default instances of certificate profiles are for particular types of certificates including a CA certificate, SSL server certificate, end-entity certificate, and so on. Each certificate profile is associated with the certificate profile form in the end entity interface that lists all of the available certificate profiles. The end entity chooses the certificate profile when submitting the request. You can customize this form. Any enabled certificate profiles will appear as links on this form. Those links take the user to a dynamically created HTML page that is generated based on the inputs set in the certificate profile.

Each certificate profile that will be used is configured by an administrator. The administrator configures defaults and constraints, inputs, outputs, and specifies the authentication method for each certificate profile.

The certificate profiles that have been configured are listed in the agent services interface where the agent has to approve the certificate profile to enable it. Once the certificate profile is enabled, it appears in the end entity interface.

When an end entity submits a request using a particular certificate profile, the certificate profile authenticates the request based on the authentication mechanism associated with that certificate profile—and thus the enrollment method. The certificate is issued following the constraints and extensions set in that certificate profile.

For detailed information, see Chapter 11 "Certificate Profiles."

Configuring Publishing

You can publish certificates and CRLs to files or to an LDAP directory, and publish CRLs to an Online Certificate Status Manager.

The publishing feature allows you to determine which certificates and which CRLs are published to which locations. The flexible plug-in interface provides the ability to publish the same certificate or CRL to a number of places, and to determine a subset of certificates or a particular CRL to publish to a single location.

For detailed information, see Chapter 16 "Publishing."

Configuring OCSP Services

The Certificate Manager contains an internal OCSP responder which is installed by default. The OCSP responder receives standard OCSP requests via the non-SSL end-entity port. It checks the status of certificates in the internal database and then reports back on the status of the certificate.

The Online Certificate Status Manager is a stand-alone subsystem that a Certificate Manager publishes CRLs to. This subsystem receives standard OCSP requests for certificate status and checks the CRLs to see if the certificate has been revoked. This subsystem can be configured with more than one Certificate Manager.

See Chapter 5 "OCSP Responder" for information about both of these services.

Setting Up CRLs

The CRL feature allows you to set up CRLs that are issued on a periodic basis. You can also define issuing points so that a CRL from that issuing point contains only the list of revoked certificates associated with that issuing point. You can also create delta CRLS. When you install, the CRL feature is setup, but the creation of CRLs is disabled. You need to enable it and configure issuing points to issue CRLs. For detailed information on setting up CRLs, see Chapter 15 "Revocation and CRLs."

Setting Up Notifications

The notification feature that allows you to send automated notifications is disabled after installation. You can set up three types of automatic notifications:

You need to enable and configure notifications in order to use this feature. For detailed information on setting up notifications, see Chapter 13 "Automated Notifications."

Setting Up Jobs

The jobs feature that allows you to run automated jobs is disabled after installation. You need to enable and configure jobs in order to use this feature. For detailed information on setting up jobs, see Chapter 14 "Automated Jobs."

Customizing the End Entity Interface

CMS provides you with a set of forms that are available at the end entity interface and are preconfigured for various types of interaction with the end entity. You can customize this interface by changing which forms are available, and by changing the forms themselves. You might change the look and feel of the form to fit in with your intranet, you might change what method of authentication is associated with a form, and you might change which policies are associated with the form.

Adding Data Recovery Services

You can set up a trusted relationship between a Data Recovery Manager and a Certificate Manager so that the end-entities' private encryption keys are archived during the certificate request. See Chapter 6 "Data Recovery Manager."

Setting Up a CMC Client

This section describes some utilities that demonstrate how to write a CMC client.

CMC Request Utility

The CMC Request Utility, CMCRequest, is used to create a CMC request from one or more PCKS #10 or CRMF requests. The utility can also be used to revoke certificates. It is installed along with CMS and is available in the following directory:

<server_root>/bin/cert/tools

This utility takes a single .cfg file as a parameter. The .cfg file must include the formatted CMC request:

CMCRequest <full pathname to .cfg file>

For revocation requests, the revRequest.enable parameter (described below) must be set to true and related parameters must contain the appropriate information.

The .cfg file contains these parameters:

numRequests. The total number of PCKS #10 or CRMF requests. In some cases, the value of this parameter can be 0.

Example: numRequests=1

input. The full path, including the filename, for the PCKS #10 or CRMF request, which must be in base-64 encoded format. Multiple filenames are separated by white space. This is a required parameter if numRequests > 0.

Example: input=crmf1

output. The full path, including the filename, for the resulting CMC request in binary format. This is a required parameter.

Example: output=cmc

nickname. Nickname of the agent certificate used to sign the full CMC request. This is a required parameter.

Example: nickname=CMS Agent-102504a's 102504a ID

dbdir. Full path to the directory where cert8.db, key3.db, and secmod.db are located. This is a required parameter.

Example: dbdir=/u/smith/db/

password. Password for cert8.db, which stores the agent certificate. This is a required parameter.

Example: password=netscape

format. Request format, either pkcs10 or crmf.

Example: format=crmf

 

The following parameters specify CMC control attributes:

confirmCertAcceptance.enable. If true, then the request will contain this control. Absence of this parameter is interpreted as false.

Example: confirmCertAcceptance.enable=false

confirmCertAcceptance.serial. The serial number for the confirmCertAcceptance control.

Example: confirmCertAcceptance.serial=3

confirmCertAcceptance.issuer. The issuer name for the confirmCertAcceptance control.

Example: confirmCertAcceptance.issuer=cn=Certificate Manager,ou=102504a,o=102504a,c=us

getCert.enable. If true, then the request will contain this control attribute. Absence of this parameter is interpreted as false.

Example: getCert.enable=false

getCert.serial. The serial number for the getCert control.

Example: getCert.serial=300

getCert.issuer. The issuer name for the getCert control.

Example: getCert.issuer=cn=Certificate Manager,ou=102504a,o=102504a,c=us

dataReturn.enable. If true, then the request will contain this control attribute. Absence of this parameter is interpreted as false.

Example: dataReturn.enable=false

dataReturn.data. Data contained in the dataReturn control.

Example: dataReturn.data=test

transactionMgt.enable. If true, then the request will contain this control. Absence of this parameter is interpreted as false.

Example: transactionMgt.enable=true

transactionMgt.id. Transaction identifier for transactionMgt control. VeriSign recommends that the transaction ID should be an MD5 hash of the public key.

senderNonce.enable. If true, then the request will contain this control attribute. Absence of this parameter is interpreted as false.

Example: senderNonce.enable=false

senderNonce.id. sender nonce for the senderNonce control.

Example: senderNonce.id=testing

revRequest.enable. If true, then the request will contain this control. Absence of this parameter is interpreted as false.

Example: revRequest.enable=true

revRequest.nickname. The nickname for the certificate being revoked.

Example: revRequest.nickname=newuser's 102504a ID

revRequest.issuer. The issuer name for the certificate being revoked.

Example: revRequest.issuer=cn=Certificate Manager,ou=102504a,o=102504a,c=us

revRequest.serial. The serial number for the certificate being revoked.

Example: revRequest.serial=75

revRequest.reason. The reason for revoking this certificate. Use one of these values: unspecified, keyCompromise, caCompromise, affiliationChanged, superseded, cessationOfOperation, certificateHold, or removeFromCRL.

Example: revRequest.reason=unspecified

revRequest.sharedSecret. The shared secret for the revocation request.

Example: revRequest.sharedSecret=testing

revRequest.comment. The human readable comment for the revocation request.

Example: revRequest.comment=human readable comment

revRequest.invalidityDatePresent. If true, the current time will be the invalidity date for the revoked certificate. If false, no invalidity date is present.

Example: revRequest.invalidityDatePresent=false

identityProof.enable. If true, then the request will contain this control attribute. Absence of this parameter is interpreted as false.

Example: identityProof.enable=false

identityProof.sharedSecret. Shared secret for identityProof control.

Example: identityProof.sharedSecret=testing

popLinkWitness.enable. If true, then the request will contain this control attribute. Absence of this parameter is interpreted as false.

Example: popLinkWitness.enable=false

LraPopWitness.enable. If true, then the request will contain this control attribute. Absence of this parameter is interpreted as false.

Example: LraPopWitness.enable=false

LraPopWitness.bodyPartIDs. List of body part IDs for the LraPopWtiness control. Each bodyPartID is separated by space.

Example: LraPopWitness.bodyPartIDs=1

HTTP Client Utility

The HTTP Client Utility, HttpClient, is used to send a CMC request (created with the CMC Request Utility) or a PKCS #10 request to a CA. It is installed along with CMS and is available in the following directory:

<server_root>/bin/cert/tools

This utility takes a single .cfg file as a parameter:

HttpClient <full pathname to .cfg file>

where the .cfg file contains these parameters:

host. Host name for the CMS server.

Example: host=server.com

port: Port number for CMS server.

Example: port=1028

secure: true for an HTTPS connection, false for an HTTP connection

Example: secure=true

input. Full path, including filename, for the enrollment request, which must be in binary format

Example: input=cmcReqCRMFBin

output: The full path, including the filename, for the response in binary format.

Example: output=cmcResp

dbdir. Full path to the directory where cert8.db, key3.db, and secmod.db are located. This parameter will be ignored if secure=false

Example: dbdir=<server_root>/bin/cert/tools

clientmode. true for client authentication, false for no client authentication. This parameter will be ignored if secure=false

Example: clientmode=true

password. Password for cert8.db. This parameter will be ignored if secure=false and clientauth=false.

Example: password=netscape

nickname. Nickname for client certificate. This parameter will be ignored if clientmode=false.

Example: nickname=CMS Agent-102504a's 102504a ID

servlet. The URI of the servlet that processes full CMC requests. The default value is /ca/profileSubmitCMCFull.

Example: servlet=/ca/profileSubmitCMCFull

CMC Response Utility

The CMC Response Utility, CMCResponse, is used to parse a CMC response (received by the HTTP Client utility). It is installed along with CMS and is available in the following directory:

<server_root>/bin/cert/tools

The CMC Response utility uses this syntax:

CMCResponse -d <location of cert8.db> -i <full pathname, including filename, to CMC response in binary format>

The parsed output is printed to the screen.

Sending a Simple CMC Request

To send a simple CMC request (that is, a plain PKCS #10 request), follow these steps:

  1. Use the AtoB tool in <server_root>/bin/cert/tools to convert the base-64-encoded PKCS #10 request to binary form.
  2. Use the HTTP Client Utility to send the request.

By default, the URI of the servlet that processes a simple CMC request is /ca/profileSubmitCMCSimple.

Setting Up the CMCAuth Authentication Plug-in

This plug-in verifies the signature of the full CMC request. That is, it verifies that the person who signed the request is the authorized agent. If everything is fine, the CMC request will be processed right away.

Note: This method of authentication is set up by default. You need to perform the following procedure only if you deleted the instance that was set up by default.

To set up this form of authentication:

  1. In the CMS window for the Certificate Manager issuing the certificates, select the Configuration tab.
  2. Select Authentication in the navigation tree.
    3. The right pane shows the Authentication Instance tab listing currently configured authentication instances.
     
  3. Click Add.
    4. The Select Authentication Plug-in Implementation window appears.
     
  4. Select the CMCAuth plug-in module.
  5. Click Next.
    6. The Authentication Instance Editor window appears.
     
  6. If you don't want to use the default instance name, in the Authentication Instance ID field, type a unique name for this instance that will help you identify it. If you chose to use a different name, be sure to edit the default name in the enrollment forms.
    7. There are no configuration options for this plug-in; it simply enables this functionality.
     
  7. Click OK. The authentication instance is now set up and enabled.

Setting Up the Server for Multiple Requests in a Full CMC Request

CMC supports multiple CRMF or PKCS #10 requests in a single full CMC request. If the numRequests parameter in the .cfg file > 1, you need to modify the server's certificate profile. To do so, follow these steps:

  1. By default, the servlet processing a full CMC request uses the profile caFullCMCUserCert. Currently, this profile handles a single request only. If you expect to send full CMC requests that contain n requests, make sure you have n number of setIDs on the policyset.list line in caFullCMCUserCert.cfg, located in <server_root>/cert-<instanceid>/profiles/ca/. You also need to specify new policy rules for each newly created policy setID.
  2. To use the new profile instead of the default one, you must modify web.xml, located in <server_root>/cert-<instanceid>/webapps/ee/WEB-INF/. Locate the servlet (by default, /ca/profileSubmitCMCFull) used to process the full CMC request, and change the value for the parameter profileID to the name of your new profile.
    3. Note: For information on creating a new profile, see Chapter 11 "Certificate Profiles."
     
  3. Restart the server.

How The Certificate Manager Works

This section provides detailed information on how the Certificate Manager works during Enrollment, Renewal, Revocation, and Publishing of certificates and CRLs to help you better understand what configuration you will need to perform for your PKI.

Enrollment

An end entity can enroll in your PKI by submitting an enrollment request via the end-entity interface. You can create more than one type of enrollment that either uses a different enrollment method, has different certificate issuance policies, or requires a different method of authentication, or all three. You can do this by creating separate enrollment pages that are specific to the type of enrollment, type of authentication, and the certificate issuance policies associated with this type of certificate. The forms associated with enrollment are customizable allowing you to change the content and the look and feel of the forms. See "Customizing the End Entity Interface" for information on the default forms. See the Netscape Certificate Management System Customization Guide for information on customizing these forms. You can also do this by creating certificate profiles for each with a dynamically generated form associated with each certificate profile. You customize the dynamically created certificate profile forms by configuring the inputs associated with the certificate profile.

The Certificate Enrollment Process

When an end-entity enrolls in your PKI requesting a certificate, a number of things can happen depending on your configuration and the subsystems you have installed. The following lists those events in the approximate order they occur:

Renewal

The Certificate Manager allows for the renewal of certificates. Certificates can be renewed if the policies associated with renewal are enabled and if the request meets the criteria of those policies. The Certificate Manager is set up for a single method of renewal. All requests are made to the renewal page of the end-entity interface. The end entity presents their old certificate, and if they meet the policies for renewal, a new certificate is issued with the validity period set up in the renewal policies.

Whether you set up renewals as renewals, or have end entities renew certificates as an enrollment request, you can set up automated notifications that will send an email to users at some period before their certificate expires for a predefined interval of time. You set this up by enabling the jobs feature, enabling and configuring Certificate Renewal job, and customizing the certificate renewal email template.

Revocation

An end entity can request that their own certificate is revoked.

When an end entity makes the request, they are asked to present their certificate. If they have the certificate and the key materials, the request is processed and sent to the Certificate Manager and the certificate is revoked. Once approved, the signed request is sent to the Certificate Manager and the certificate is revoked. The Certificate Manager marks the certificate as revoked in its database, and adds it to any CRLs that are applicable.

An agent can revoke any certificate issued by the Certificate Manager. They do this by searching for the certificate in the agent services interface and then marking it revoked.

Once a certificate is revoked, it is marked revoked in the database, and in the publishing directory if the Certificate is set up for publishing.

If you enabled and configured the internal OCSP service, the service determines the status of certificates by looking them up in the internal database and reporting on the status of the certificate.

You can set up an automated notifications that send an email message to the end entity when their certificate is revoked. You set this up by enabling and configuring the Certificate Revoked notification message, and customizing the email template associated with this notification.

Federal Bridge CA

CMS supports Federal Bridge Certificate Authority (FBCA) by providing the capability to issue, import, and publish cross-pair CA certificates.

With cross-pair certificates, one CA signs and issues a cross-pair certificate to a second CA, and the second CA signs and issues a cross-pair certificate to the first CA. Both CAs then store and or publish both certificates as a crossCertificatePair.

This may be done when you want to honor certificates issued by a CA that does not chain up to your root CA. By establishing a trust between your CA and another CA through a cross-pair CA certificate, you can download this cross-pair certificate using it to trust the certificates that are issued by the other CA.

Issuing Cross-Pair Certificates

The policy feature allows you to configure the policy CertificatePoliciesExt and provide HTTP_PARAMS.certType==fbca as the predicate value, and then set up any other necessary policies for this kind of certificate. You would then associate an end-entity enrollment page, customized to enroll for cross-pair certificates, providing the hidden value certType==fbca, thus activating policies associated with FBCA to this request.

You can also use the Certificate Setup wizard to create a cross-pair certificate request that can be sent to another CA. You might create this request and then paste it into an existing end-entity interface enrollment page, or a customized page that requires a request rather than forming the request from that page.

See Chapter 12 "Policies" for more information about policies.

Importing Cross-Pair Certificates

CMS provides the capability to import the cross-pair certificates from each of the CAs. You use the Certificate Setup wizard to import both certificates. When both certificates have been imported into the database, a crossCertificatePair is formed and stored in the database. The original certificates are deleted once the crossCertificatePair is formed.

You can search for and view a crossCertificatePair in the database using the following LDAP search command:

./ldapsearch -h <yourHostName> -p <yourCAInternalDBPort >
-b "o=netscapeCertificateServer" -D "cn=Directory Manager"
-w <DirectoryManagerPassword> "cn=crossCerts"

See "Certificate Setup Wizard"" for more information about the Certificate Setup Wizard.

Publishing Cross-Pair Certificates

You can publish cross-pair certificates (as a crossCertificatePair) to either an LDAP directory or to a file. When you set up publishing, you can specify cross-pair certificates in the rule you set up for this type of certificate by selecting xcerts in the type field of the Rule Editor window. CMS provides a rule called LDAPXCertRule that is pre configured for publishing cross-pair certificates.

CMS also provides a publishing mapper for CA certificates that can be used for publishing cross-pair certificates, LDAPCA, designating which LDAP entry should be used to store the crossCertificatePair. A publisher, LDAPCrossPairPublisher, is also set up specifying the attribute used to store the cross-pair certificate in the CA entry. This is set to crossCertificatePair;binary.

See Chapter 16 "Publishing" for more information about publishing.

Cloning a CA

Cloning a Certificate Manager is the process of creating two server processes performing the same CA functions: you create another instance of a Certificate Manager and configure it to use the same CA signing key and certificate to issue certificates with serial numbers that do not conflict or overlap with the serial numbers of the Certificate Manager that's being cloned.

You can use the cloning feature for CA scalability and for setting up a PKI with CAs organized in a flat structure as opposed to a hierarchical structure. For example, if you don't want your PKI to be a CA hierarchy comprising root and subordinate CAs, you can clone the Certificate Manager and configure the clone to issue certificates that fall within a distinct range of serial numbers. Because clone CAs and original CAs use the same CA signing key and certificate to sign the certificates they issue, the issuer name in all the certificates in such a setup will be the same. Clone CAs and the Certificate Managers they clone issue certificates as if they are a single CA, and can be placed on different hosts for high availability failover support.

When you setup a Certificate Manager clone, the clone and the original share the the revocation status of the certificates they have issued. Though the clone CA cannot generate the CRL itself, it can revoke certificates, display, import, and download previously generated CRL lists. This is because data sources for the cloned systems are replicated, so that the data is shared seemlessly between subsystem databases. See " for information on how to set up cloned instances replication between the cloned databases.

If you enable the OCSP-service feature built into the Certificate Manager, it can function as a full-fledged OCSP responder for your PKI. Like the CA itself, the OCSP responder can be cloned.

OCSP-compliant clients can query the Certificate Manager for the revocation status of any certificate, whether that certificate was generated by the original CA or a clone, and whether the OCSP responder is itself an originals or a clone. See Cloning the Online Certificate Status Manager for information about cloning the OCSP Responder.



Previous      Contents      Index      DocHome      Next     

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


Last Updated November 23, 2004