Use of this product is subject to the terms detailed in the license agreement accompanying it.

Contents

CMS Documentation

After you run the setup script as described under Installation Procedure below, see <server_root>/manual/index.html for a complete list of the documentation installed with the product.

If you are working with files you have downloaded from the web site, as opposed to the files on the CD, the Docs directory mentioned above will not be present. Instead, you must first run the setup script, then check <server_root>/manual/index.html for the documentation.

For the latest information about Certificate Management System, including current release notes, technical notes, and deployment information, check this URL:
http://developer.iplanet.com/docs/manuals/cms.html

Software/Hardware Requirements

Operating Systems Supported

Windows NT 4.0 with Service Pack 4 and NTFS, Solaris 2.5.1, Solaris 2.6

Other Required Software

Netscape Administration Server 4.1 (included)

Netscape Directory Server 4.1 (included)

Browser software that supports SSL

 Platform and Hard Disk Requirements

In addition to the requirements listed below, make sure you have ample swap space or virtual memory allocated for the system on which you intend to install the Certificate Management System..

Solaris Platform Requirements:

• RAM: 128 MB (required)
• Hard disk storage space requirements -- total required is approximately 250 MB, as follows:
• Total transient space required during installation: 100 MB
• Hard disk storage space required for installation:
• Space required for setup, configuration, and running the server: approximately 100 MB
• Additional space to allow for database growth in pilot deployment: approximately 50 MB
• Total disk storage space for installation: approximately 150 MB
• This release was tested against patch level 103640-12.
 

Windows NT Platform Requirements:

• Windows NT Service Pack 4
• 128 MB of RAM (recommended)
• Pentium 166 or faster
• Software must be installed on NTFS (FAT file system will not work due to Directory Server 4.1 restriction)
• Hard disk storage space requirements -- total required is approximately 250 MB, as follows:
• Total transient space required during installation: 100 MB
• Hard disk storage space required for installation:
• Space required for setup, configuration, and running the server: approximately 100 MB
• Additional space to allow for database growth in pilot deployment: approximately 50 MB
• Total disk storage space for installation: approximately 150 MB

 Other Requirements

On Unix systems, you must install as root in order to use well-known port numbers (such as 443) that are less than 1024. If you do not plan to use port numbers less than 1024, you do not need to install as root. If you plan to run as root, you should also install as root and specify the default run-as user and group, nobody.

Administration Server, version 4.1

Directory Server, version 4.1

Built with NSS, version 2.6

Installation Procedure

As explained in the documentation, installation involves four stages:

• Stage 1: Run the installation script (setup on Unix, setup.exe on Windows NT) to install administration and directory servers as necessary, and perform the initial phase of CMS installation.
• Stage 2: Run the Installation Wizard to set up the initial configuration of the CMS instance. This is where you specify which subsystems are to be part of this instance.
• Stage 3: Use Netscape Console to further configure the new CMS instance as needed. For example, you must provide it with information about the LDAP publishing and authentication directories.
• Stage 4: If you wish, use Netscape Console to create additional instances of the Certificate Management System in the same server root directory, and use the Installation Wizard to configure them.

Notes on Features

An Alpha Build of a Dual-Key Test Bed for Communicator 4.5

• An alpha build of a Dual-Key Test Bed for Communicator 4.5 is included in the domestic version of this release. For more information about the test bed installation, see the release notes available here: <server_root>/bin/cert/nsm/NSM_RELNOTES.html

• This alpha build of the Dual-Key Test Bed works for server-side SSL authentication, one-click enrollment, and client authentication with automatic certificate selection. Attempts to use other security features of the test bed will fail, including the following:
• manual enrollment
• importing a certificate
• renewal and revocation
• retrieving a CA chain
• any agent operation

• For the most recent builds of the Dual-Key Test Bed, contact technical support.

NSS Integration

• Uses NSS for SSL, Certificate Manager certificate, and CRL signing.
• Does not use NSS for random number generation yet.

Certificate Manager and Registration Manager Subsystems

• Certificate Enrollment
• User Certificate Enrollment based on Directory Authentication
• Server Certificate Enrollment without authentication (manual authentication)

• Browser Types
• Netscape Communicator 4.x
• Microsoft Internet Explorer (IE) 4.x

• Key Type, Key Length, and Signing Algorithms Supported
• RSA and DSA
• 512 to 2048 bits
• CA signing with MD5 RSA, SHA1 RSA, and SHA1 DSA

• URL for Enrollment
• Go to http://<host_name>:<non-SSL port> or https://<host_name>:<SSL port>, then select End Users Services.

For details on forms and template management, see Netscape Certificate Management System Administrator's Guide, available after installation here: <server_root>/manual/en/cert/pdf/cs40_adm.pdf

• Certificate Signing Default Policy
• Default validity period - 365 days
• Default certificate version - version 3 or v3
• Extensions set by default
• Netscape Certificate Type extension
• Key Usage extension
• Basic Constraints extension

Known Bugs/Issues for 4.1 Release

• Administration Server
• Authentication
• Browser
• CEP Support
• CRLs
• Directory Server
• DSA
• Enrollment
• Enterprise Server
• Extensions
• Hardware Tokens
• Installation
• Internationalization Support
• Job Scheduling/Notification
• LDAP Publishing
• Logging
• Migration Tool
• Miscellaneous
• Performance
• Policies
• Remote Registration Manager
• Renewal of CMS Certificates
• Request Queue Processing
• Samples and SDKs
• Scalability/Sizing
• Searching for Certificates
• Starting/Stopping the Server
• UI (Netscape Console/CMS Window)
• Uninstallation

• Netscape Administration Server does not support EXCEED X server software for running Unix X-Windows applications on Windows NT. Therefore, EXCEED will not run reliably with Netscape Certificate Management System.

• Netscape Administration Server might crash when you create or remove a CMS instance. If this happens, go to the command line and start the Administration Server. For instructions on starting the Administration Server, see the section named "Starting Administration Server" in Chapter 2, "Administration Tasks and Tool" of Netscape Certificate Management System Administrator's Guide. [# 352824 and # 352372]

• When naming an authentication instance (or rule), be sure to formulate the name using any combination of letters (aA to zZ), digits (0 to 9), an underscore (_), and a hyphen (-); other characters and spaces are not allowed. For example, you can type Pin_Dir_auth or PinDirAuth as the instance name, but not Pin Dir Auth.

• The configuration variable named dnpattern of UidPwdDirAuth and UidPwdPinDirAuth authentication module instances, doesn't support a comma (,) in a constant. The workaround for having a comma in a DN is to escape it with a backward slash (\) and enclose the DN in double quotation marks (" ") as shown in the example below:

O="Netscape Communication \, Corp."

• The dnpattern configuration variable of UidPwdDirAuth and UidPwdPinDirAuth authentication module instances now supports escaped commas and multiple attribute variable assertions (AVAs) in a RDN. Below is the syntax followed by examples. Note that dnpattern is a string representing a subject name pattern to formulate from the directory attributes and entry dn. If empty or not set, the LDAP entry DN will be used as the certificate subject name. For background information on this parameter, see Table 9.1 and Table 9.2 in Chapter 9, "Introduction to Authentication" of Netscape Certificate Management System Administrator's Guide.

Syntax:

dnPattern := rdnPattern *[ "," rdnPattern ]
rdnPattern := avaPattern *[ "+" avaPattern ]
avaPattern := name "=" value | name "=" "$attr" "." attrName [ "." attrNumber ] | name "=" "$dn" "." attrName [ "." attrNumber ] | "$dn" "." "$rdn" "." number

Example 1:
 
E=$attr.mail.1, CN=$attr.cn, OU=$dn.ou.2, O=$dn.o, C=US
LDAP entry: dn:  UID=jjames, OU=IS, OU=people, O=siroe.com
LDAP attributes: cn: Jesse James
LDAP attributes: mail: jjames@siroe.com

The subject name formulated will be as follows:

E=jjames@siroe.com, CN=Jesse James, OU=people, O=siroe.com, C=US
E = the first 'mail' ldap attribute value in user's entry.
CN = the (first) 'cn' ldap attribute value in the user's entry.
OU = the second 'ou' value in the user's entry DN.
O = the (first) 'o' value in the user's entry DN.
C = the string "US"

Example 2:
 
E=$attr.mail.1, CN=$attr.cn, OU=$dn.ou.2, O=$dn.o, C=US
LDAP entry: dn:  UID=jjames, OU=IS+OU=people, O=siroe.com
LDAP attributes: cn: Jesse James
LDAP attributes: mail: jjames@siroe.com
The subject name formulated will be as follows:

E=jjames@siroe.com, CN=Jesse James, OU=people, O=siroe.com, C=US
E = the first 'mail' ldap attribute value in user's entry.
CN = the (first) 'cn' ldap attribute value in the user's entry.
OU = the second 'ou' value in the user's entry DN. note multiple AVAs in a RDN in this example.
O = the (first) 'o' value in the user's entry DN.
C = the string "US"

Example 3:
 
CN=$attr.cn, $rdn.2, O=$dn.o, C=US
LDAP entry: dn:  UID=jjames, OU=IS+OU=people, O=siroe.com
LDAP attributes: cn: Jesse James
LDAP attributes: mail: jjames@siroe.com

The subject name formulated will be as follows:

CN=Jesse James, OU=IS+OU=people, O=siroe.com, C=US
CN = the (first) 'cn' LDAP attribute value in the user's entry followed by the second RDN in the user's entry DN.
O = the (first) 'o' value in the user's entry DN.
C = the string "US"

Example 4:

CN=$attr.cn, OU=$dn.ou.2+OU=$dn.ou.1, O=$dn.o, C=US
LDAP entry: dn:  UID=jjames, OU=IS+OU=people, O=siroe, com
LDAP attributes: cn: Jesse James
LDAP attributes: mail: jjames@siroe.com

The subject name formulated will be as follows:

CN=Jesse James, OU=people+OU=IS, O="siroe \, com", C=US
CN = the (first) 'cn' ldap attribute value in the user's entry.
OU = the second 'ou' value in the user's entry DN followed by the first 'ou' value in the user's entry. Note multiple AVAs in a RDN in this example.
O = the (first) 'o' value in the user's entry DN.
C = the string "US"

If an attribute or subject DN component does not exist the attribute is skipped. [# 343200]

• When using the remove pin option of the PinDirEnrollment plug-in, ACIs must be set up on the directory to prevent users from creating new PINs for themselves.
1. Create a user entry for the PIN manager.
2. Assuming you just have one privileged user 'uid=pinmanager, ou=people, o=mcom.com' who you want to be able to create PINs, use an ACI such as the one below to allow access from that user, and prevent access from all others.

dn: ou=People, o=mcom.com
changetype: modify
add: aci
aci: (target="ldap:///ou=People, o=mcom.com")(targetattr="pin || objectclass")
 (version 3.0; acl "Pincontrol";
 allow (all) userdn = "ldap:///uid=pinmanager,ou=People,o=mcom.com";
 deny(proxy,selfwrite,compare,add,write,delete,search)
 userdn != "ldap:///uid=pinmanager,ou=People,o=mcom.com"; )
3. Put the above ACI in a text file called aci.ldif.
4. Copy the file to this directory: <server_root>/shared/bin
5. Open a command window.
6. Go to this directory: <server_root>/shared/bin
7. Run the ldapmodify command to add the ACI to the authentication directory:

ldapmodify -c -v -p 389 -D "CN=Directory Manager" -w password -f aci.ldif
8. When you use the setpin tool, you should now bind as the pinmanager user.
Next, when configuring the PIN-based enrollment plug-in (identified as UidPwdPinDirAuth) to remove the PIN after enrollment, here's what you must do:
1. Create an instance for the UidPwdPinDirAuth plug-in.
1. Login to Netscape Console.
2. Login to CMS window.
3. In the navigation tree, click Authentication.
4. In the right pane, click Add.
5. Choose UidPwdPinDirAuth and click Next.
6. For the instance name, choose the default name (PinDirEnrollment) suggested by the server. This way, you won't have to edit the enrollment page to identify the instance.
7. Fill in the required parameters, such as the location and DN with which to bind to the directory and the method/type of authentication, in the configuration window. For details on individual parameters check the CMS Administrator's Guide.
8. Make sure to set the removePin argument to false.
2. Next, stop the server.
1. Click the Tasks tab.
2. Click Stop the Server.
3. Edit the configuration file.
1. Go to this directory: <server_root>/cert-<instance_id>/config/
2. Open the CMS configuration file (CMS.cfg) in an editor.
3. Locate this line: auth.instance.PinDirEnrollment.ldap.removePin=false
4. Change the value of the removePin argument from false to true.
4. Start the server from the command line. This is a must.
1. Open a command window.
2. Go to this directory: <server_root>/cert-<instance_id>
3. At the prompt, enter this: start-cert

You are prompted for the password for the DN mentioned previously. Remember that this must be the DN that identifies the only user who has privileges to modify the PIN attribute in the directory.
Once you configure the server, it automatically removes PINs from the directory following successful authentication by the user. However, if the request then fails for some other reason, for example, if it is rejected by policy, the user will not be able to enroll again because the PIN will already have been deleted. [# 347313 & 370758]

• Agents and administrators must be users in the Certificate Management System user and group database. This will be replaced by ACLs in future releases.

• Table 9.1 and Table 9.2 in Chapter 9, "Introduction to Authentication" of Netscape Certificate Management System Administrator's Guide does not list the following configuration parameters that are supported by the UidPwdPinDirAuth authentication plug-in module:
• Table 9.2 in the section "Directory-Based Authentication" with PINs in Chapter 9, "Introduction to Authentication" of Netscape Certificate Management System Administrator's Guide does not list the following configuration parameters that are supported by the UidPwdPinDirAuth authentication plug-in module:

Additional configuration parameters supported by the UidPwdPinDirAuth authentication plug-in module

Parameter name	Description
ldap.ldapauth.authtype	Specifies the authentication type -- basic authentication or SSL client authentication -- required in order to remove PINs from the authentication directory. Enter either of the following: BasicAuth -- Enter this for basic authentication. Be sure to enter the correct values for the ldap.ldapauth.bindDN and ldap.ldapauth.bindPWPrompt parameters; the server uses the DN from the ldap.ldapauth.bindDN attribute to bind to the directory. SslClientAuth -- Enter this for SSL client authentication. Be sure to set the value of the ldap.ldapconn.secureConn parameter to true and the value of the ldap.ldapauth.clientCertNickname parameter to the nickname of the certificate to be used for SSL client authentication.
ldap.ldapauth.clientCertNickname	Specifies the nickname of the certificate to be used for SSL client authentication to the authentication directory in order to remove PINs. Make sure that the certificate is valid and has been signed by a CA that is trusted in the authentication directory's certificate database.

• Table 9.1 and Table 9.2 in Chapter 9, "Introduction to Authentication" of Netscape Certificate Management System Administrator's Guide lists ldapAttributes as one of the parameters supported by the corresponding authentication plug-in. Instead, both the plug-ins support two parameters named ldapStringAttributes and ldapByteAttributes which are documented in the table below.
 

Parameter name	Description
ldapStringAttributes	Specifies the list of LDAP string attributes that should be considered authentic for the end entity. If specified, the values corresponding to these attributes will be copied from the authentication directory into the authentication token -- that is, values retrieved from this parameter can be used by policy modules to form subject names or to make other policy decisions (see Subject Alternate Name Extension policy). Entering values for this parameter is optional. You may enter any valid LDAP attributes, separated by commas. Example: mail, mailalternateaddress This sample configuration specifies that the LDAP attributes mail and mailalternateaddress should be stored in the authentication token.
ldapByteAttributes	Specifies the list of LDAP byte (binary) attributes that should be considered authentic for the end entity. If specified, the values corresponding to these attributes will be copied from the authentication directory into the authentication token -- that is, values retrieved from this parameter can be used by policy modules to make certain policy decisions or to add additional information to users’ certificates. For example, assume you have defined an LDAP binary attribute for storing users’ pictures or fingerprints in your directory. You could develop a policy plug-in module that adds users’ pictures to their certificates as extensions. Entering values for this parameter is optional. You may enter any valid LDAP attributes, separated by commas. Example: photo This sample configuration specifies that photo should be stored in the authentication token.

• Microsoft Internet Explorer 3.x and Netscape Navigator 3.x are not fully supported by the default HTML interfaces for Agent Services (of the Registration Manager, Certificate Manager, and Data Recovery Manager). For best results, use Communicator 4.x or Internet Explorer 4.x.

• Client time drift detection on IE is disabled -- the HTML forms provided for end-user enrollment and renewal include JavaScript code (function named checkClientTime) that detects the time drift between the client and server clocks and prompts users to adjust their clocks (to be in sync with that of the server). This feature works only with Communicator. [# 341838]

• If you view a CRL as an agent using IE or Communicator, then revoke a certificate, and then view the CRL again, you will not see the certificate you just revoked listed in the CRL. To work around, exit the browser, relaunch it, and then view the CRL again. [# 347146]

• Communicator will crash when asked to do SSL client authentication if the DN for an SSL server certificate or a CA certificate does not have the O= attribute. However, there is a warning message displayed in the Installation Wizard if O= is left out of the DN when creating the certificates. This problem is fixed in Communicator 4.6.

• Communicator shows an error dialog when connecting with SSL to Netscape Enterprise Server, if the SSL certificate was generated with the Key Usage Extension policy turned on. To work around, turn off or disable the Key Usage Extension policy module. [# 344996]

• IE fails to present a dialog asking the agent user to specify the certificate to be used for SSL client authentication to the second server, when two SSL servers are configured on the same machine. This problem occurs when you connect to two different servers running on two different ports of the same machine. When you do SSL client authentication to the first server, IE  presents a dialog box  from which you can choose the certificate you want to use to authenticate. When you connect to the other server on the same machine, IE assumes that you want to use the same certificate and doesn't provide you with an opportunity to change your selection. The result is that you fail to authenticate to the second server, because IE automatically presents the certificate you chose previously. The workaround is to restart IE (after authenticating to the first server) and then attempt to authenticate to the second server; when you restart, you can connect to the other server and you will again be presented with a dialog box for choosing an SSL client certificate. [# 350416]

• If you are using the Solaris version of IE to get a certificate using directory-based user enrollment, Certificate Management System successfully imports the certificate, but IE crashes. [# 347824]

• If IE 4.x is configured to prompt the user for a confirmation when a form is being submitted, the request will be submitted correctly. However, a second browser window may appear. [# 355696]

• See the ones listed in the DSA section.

For more information about Certificate Enrollment Protocol (used by Cisco routers), including how to publish router certificates to a directory and how to configure automated enrollment for routers, see the CEP Enrollment with Certificate Management System 4.1 document, which is at this URL:

http://developer.iplanet.com/docs/manuals/cms.html
 

See # 341389 in the Remote Registration Manager section.

• By default, certificate revocation lists (CRLs) published by the Certificate Manager do not support CRL extensions. This ensures compatibility with current Netscape browsers. To turn on support for CRL extensions, follow these steps from within the CMS window of Netscape Console:

1. Select the Configuration tab.
2. In the navigation tree, select Certificate Manager.
3. In the right pane, select the Revocation List tab.
4. In the CRL Format section, select the checkbox labeled "Allow extensions".
5. Click the Save button.

• Table 19.1 in the section entitled "Updating CRLs Automatically" in Chapter 19, "Publishing CRLs" of Netscape Certificate Management System Administrator's Guide incorrectly states that the CRL extension named "Issuer alternative name" is not supported. Also, the extension named "Certificate issuer" is listed under the category CRL extension instead of CRL entry extension. The correct information is shown in the table below. [# 347029]

CRL extensions and CRL entry extensions supported by the Certificate Manager

Component	Supported	Not supported
CRL extensions	Authority key identifier CRL number Issuing distribution point Issuer alternative name	Delta CRL indicator
CRL entry extensions	Reason code Invalidity date	Certificate issuer Hold instruction code

• The section "Updating CRLs Automatically" in Chapter 19, "Publishing CRLs" of Netscape Certificate Management System Administrator's Guide states that you can configure the server to update the CRL either every time a certificate is revoked or periodically. This is no longer true. You can configure the server to update the CRL every time a certificate is revoked (or taken off hold) and at a periodic interval. The Revocation List tab in the CMS window now has check boxes, instead of radio buttons, for selecting both these options. If you select both the options, the CRL gets updated and published every time a certificate is revoked or taken off hold as well as every configured time period. [# 354337]

• If you configure the server to update the CRL automatically every time period, the server by default adds a 5 second skew to the next update time to allow time to create the CRL and publish it. For example, if you configure server to update the CRL every 20 minutes, and if the CRL is updated at 16:00:00, the CRL will be updated again at 16:19:55. You can also configure the skew by manually editing the value, which is specified in seconds, of the nextUpdateSkew parameter in the configuration file, CMS.cfg.

For example, ca.crl.MasterCRL.nextUpdateSkew=30 will set it to 30 seconds.
Note that this configuration variable can only be modified in the CMS.cfg; it is not available through the CMS window. [# 354337]

• If you are using the ValiCert plug-in with Enterprise Server, it is highly recommended that you force publish an empty CRL during the installation/configuration of your CMS system. This is so that if there are no revoked certificates, the ValiCert plug-in would not interpret it as an error and wrongly deny valid user accesses. The steps you should follow (you need to do this after all the configuration, before CMS is deployed and used) to force a CRL update is:

1. Open a web browser window.
2. Point your browser to the agent page URL, which is in this form: https://<host_name>:<agent_port>
3. Select the Update Revocation List menu.
4. Click the Update button.

• The section "CRL Issuing Points" in Chapter 19, "Publishing CRLs" of the Netscape Certificate Management System Administrator's Guide states that you can define CRL issuing points that contain a subset of the revoked certificates included in the master CRL, and points you to the http://home.netscape.com/eng/server/cms site for information on configuring the server to do so. This feature is not presently available in CMS 4.1. Please note that Certificate Management System can only publish a single CRL, also referred to as the master CRL in the documentation.

• See # 347146 in the Browser section.

• See # 353988 in the Policies section.

• See also the ones in the LDAP Publishing section.

• For all external directories such as the ones used for LDAP publishing and directory based authentication, if the directory is not up when Certificate Management System is started, it will still start; only an error will be logged. When the external Directory Server comes back up connections will automatically be remade. However, you can stop Certificate Management System from starting when any of the configured external directories are down with the help of the errorIfDown parameter in the configuration file, CMS.cfg. For example, if you set auths.instance.UserDirEnrollment.ldap.errorIfDown=true, Certificate Management System will fail to start up if the external authentication directory is down.

On the contrary, Certificate Management system will not start if the internal directory (internal database) is down.

Note that this configuration variable can only be modified in the CMS.cfg; it is not available through the CMS window. [# 345776]

• See the one listed in the Installation section.

• When a DSA signing key pair is generated for a Certificate Manager, the Configuration Wizard first generates a new set of PQG parameters. This process is computationally intensive and will result in delays of several minutes, depending on the speed of the hardware.

• Communicator 4.x is the only browser that can successfully obtain and use DSA client certificates for SSL client authentication and that can recognize the signature on SSL certificates signed by a DSA CA. IE 5.x, which does support DSA, does not recognize SSL certificates signed by a DSA CA. Navigator 3.x and IE 3.x  do not support DSA at all.

• In order for Communicator to generate a DSA key pair, you must modify the KEYGEN tag in the default certificate enrollment forms; the modifications will indicate that the DSA algorithm is to be used, and will also supply the PQG parameters. For details on the KEYGEN tag, see Netscape Extensions for User Key Generation.

Note that depending on your use of DSA, you may need to edit two KEYGEN tags in the adminEnroll.html form located here:
<server_root>/cert-<instance_id>/web/agent/ca/

Additionally, you may need to modify the KEYGEN tags in the following certificate enrollment forms:

• DirPinUserEnroll.html
• DirUserEnroll.html
• ManObjSignEnroll.html
• ManUserEnroll.html

These files are located here: <server_root>/cert-<instance_id>/web/ee/

The procedure below explains how to modify an enrollment form:

1. Open the Certificate Manager's configuration file (CMS.cfg) in a text editor.
2. Open the enrollment form in a text editor.
3. In the configuration file, find the DSSParms entry; this entry represents the PQG attribute and its value contains the PQG parameters that the CA has generated during configuration.
4. Copy the value of the DSSParms entry.
5. Go to the text editor that has the enrollment form open.
6. Search for the KEYGEN tag.
7. Insert the cursor, a space after the word KEYGEN and type the following:

keytype="DSA" PQG=

8. Paste the value of the 'DSSParms' entry following the equal to (=) sign and enclose the value you pasted in double quotes (" ").

An example of a modified KEYGEN tag is shown below (the modifications are shown in bold):

<KEYGEN keytype="DSA" PQG="MIIBHgKBgQCsQeVqw5ID/xhSe7s4vLaOuKskCFJN23OBgWCEquYIZbMZdHN7015p6n
N7XsDpTWBccLdrSdpMxmJd8rF2agb3tbk9hjZ6//MfLCTAwvegdgAzzRwB7akOgYD/SpPFb7rYu
vPfkiRjiDDrrp9r+csWqnue9uABvJtWGnW8WVYP6wIVAMCRu0u3q+PORrJxO9QcswzrLpnfAoGA
M3ZBjxLTPbXOgWIXHZnIFSpGAW1JzK5ywEtnabJWfiIRrWi3hyWLj98PcIc2cxbpOh60rwqeElU
Mv74V72Q2+HwIQwsPvTFyQUcBtOG40zlXoFwEqlaqDoXv3iA0Zp2XQy/JQFbx23J+0HKz7iB7co
04LCa0wDU7Z0x+oTwmsd0=" name="subjectKeyGenInfo">

9. Repeat steps 6 through 8 to modify any additional KEYGEN tags.
10. Save your changes.
11. Following the procedure below, configure the server to accept DSA key based certificate enrollment requests; by default, the server only accepts RSA key-based requests. [# 352662 and # 356015]

a. Open Netscape Console.
b. Open the CMS window for the Certificate Manager.
c. Click the Configuration tab.
d. In the navigation tree, select Certificate Manager.
e. Click Policies.
f. In the Policy Rules Management tab, select the KeyAlgRule entry.
g. Click the Edit/View button.
h. In the window that appears, click the parameter named algorithms and change its value from RSA to RSA,DSA.
i. Click OK.

• Once you have generated a single DSA private key with Communicator, the browser will reuse the same private key for any subsequent KEYGEN operations, rather than generating a new one. This bug can lead to the issuance of multiple certificates with identical DSA key pairs. To work around this bug, exit Communicator after generating a DSA private key, then relaunch it again. After relaunching, Communicator will generate a new DSA private key instead of reusing an existing one. You must exit Communicator after generating each DSA private key to ensure that no certificates with duplicate private keys are issued.

• For more information about using DSA for the testbed installation, see <server_root>/bin/cert/nsm/CMCJavascriptAPI.html.

• If the Data Recovery Manager's transport certificate copied into the certificate enrollment form of a Registration Manager (or Certificate Manager) is incorrect, during enrollment you will get the following error message:

Problem Processing Your Request

The Registration Manager encountered a problem while processing your request. The following is a detailed message of the error that occurred.

     Invalid Private Key

Please consult your local administrator for further assistance. The Certificate Management System logs may provide further information.

To correct this problem, modify the corresponding enrollment form to include the correct transport certificate; for details, see the section entitled Step 3. "Customize the Certificate Enrollment Form" in Chapter 25, "Recovering Encrypted Data" of Netscape Certificate Management System Administrator's Guide. [# 355937]

• No documentation on automated Registration Manager and agent enrollment -- before a new Registration Manager installation can be recognized by the Certificate Manager for which the Registration Manager will be accepting requests, the Registration Manager must be added as a privileged user to the Certificate Manager's user and group database and given membership in the Trusted Managers group. The documentation explains how you can do this manually -- first, create a privileged-user entry for the Registration Manager in the Certificate Manager's user and group database, and then add the Registration Manager's signing certificate to the database. However, it does not mention the automated process built into the request-approval forms (the page that displays the pending request) in the Agent Services interface.

In the request approval form for Registration Manager enrollment requests, the Certificate Manager agent who is handling the Registration Manager's signing-certificate request will see a checkbox labeled "This certificate is for a Trusted Manager." If selected, the checkbox indicates that the Registration Manager that has requested the certificate will be made a trusted manager for that Certificate Manager. Selecting the checkbox also requires the agent to specify a user ID for the Registration Manager. If the Certificate Manager agent approves the certificate request with the checkbox selected, the Certificate Manager automatically adds the Registration Manager as a new privileged user to its user and group database, copies the Registration Manager's signing certificate to the database, and associates the certificate with the new user's entry. Because the Registration Manager is required to do SSL client authentication (using its signing certificate) to the Certificate Manager, the new user entry created for the Registration Manager has no password.

Note that for a Certificate Manager to add the Registration Manager this way, the Certificate Manager agent who approves the Registration Manager signing certificate request must belong to both the Certificate Manager Agents and Administrators groups in the user and group database of the Certificate Manager. For more information about these groups, see the section entitled "Groups and Their Privileges" in Chapter 7, "Managing Privileged Users and Groups" in the Netscape Certificate Management System Administrator's Guide.

Similar to the Registration Manager enrollment discussed above, for client certificates a checkbox is provided on the request approval form to automatically create a privileged user and make the user an agent for the Registration Manager, Certificate Manager, or Data Recovery Manager. [# 352939]

• The console interface of Netscape version 4.x servers (for example, Netscape Directory Server) is built with a Certificate Setup Wizard which enables you to request and install an SSL server certificate for the server. You run the wizard to generate a certificate signing request (CSR), submit the request to a CA, and then install the certificate when you receive it. When the wizard generates the CSR for the key size and type you specified, you're presented with the opportunity to choose how you want to submit the CSR to the CA (see the figure below).


The choices include the following:
• To CA's email address. This option allows you to send the CSR to the CA's administrator, if you know that person's email address.
• To CA's URL. This option allows you to submit the CSR to the CA directly. To submit the CSR to Certificate Management System (Certificate Manager, to be very specific) you should enter, depending on the end entity port you want to use, either of the following URL:
 
http://<CA's_host_name>:<end_entity_port>/enrollment
or
https://<CA's_host_name>:<end_entity_SSL_port>/enrollment
Note that the request submitted to the CA's URL gets queued for approval by the Certificate Manager agent. If you want the certificate to be issued immediately, you should contact that person.


For more information on server enrollment with Certificate Management System, see section "Certificate Issuance to Servers" in Chapter 24, "Issuing and Managing End-Entity Certificates" of Netscape Certificate Management System Administrator's Guide. For more information on the Certificate Setup Wizard supported by Netscape version 4.x servers, see Managing Servers with Netscape Console. [# 359549]

• See # 344996 in the Browser section.

• Netscape Enterprise Server version 3.62 relies on the trust status of the issuer's certificate in its certificate database when validating client certificates presented during SSL client authentication -- When validating a client certificate, Enterprise Server verifies whether the CA that has signed the client certificate is trusted in its trust database. If the CA certificate is untrusted, the server rejects the client certificate. This information should be of interest to you if you have set up your Certificate Manager to function as a chained or linked CA -- that is, your Certificate Manager's CA signing certificate has been issued by a public or third-party CA.

Assume a deployment scenario in which your
• Certificate Manager is chained to a public root CA
• Certificate Manager has issued client certificates and all clients include the CA chain in their certificate databases
• Enterprise Server's certificate database includes both the public root CA certificate (trusted) and Certificate Manager's CA signing certificate (untrusted)

In this scenario, you would expect the Enterprise Server to successfully validate client certificates, but the server fails to do so because the Certificate Manager's CA signing certificate is untrusted in its database (untrusted issuer); the server doesn't check the root CA certificate for validation. [# 355999]

• See the one listed in the CRLs section.

Extensions

If you want to add multiple extensions, you should use the ExtJoiner provided as a sample in the CMS_SDK package. If you downloaded the CMS binaries from the web site, you will find the CMS_SDK directory where you unpacked/unzipped the binaries (in the same directory in which the setup program is located). If you installed Certificate Management System from a CD, check the CD for the CMS_SDK directory. The ExtJoiner is located here: CMS_SDK/cms_samples/exttools/

The ExtJoiner is a program that joins a sequence of extensions together so that the final output can be used in the wizard text field for specifying multiple extensions; note that the program doesn't generate an extension, it only joins them. The command syntax for the ExtJoiner is as follows:

java ExtJoiner <ext_file0> <ext_file1> ... <ext_fileN>
where <ext_file> specifies the path, including the filename, to files that contain the base-64 encoded DER encoding of an X.509 extension.

Step 1. Write the appropriate Java programs for the extensions.

Step 2. Join the extensions using ExtJoiner:

1. Note the file paths to the files that contain the programs for extensions.
2. Open a command window.
3. Run the ExtJoiner, substituting the appropriate file paths. For example, if you have two extension files named myExt1 and myExt2 in and have copied them to the same directory as the ExtJoiner, the command would look like this: java ExtJoiner myExt1 myExt2

You should see a base-64 encoded blob, similar to the one below, of the joined extensions on screen:
MEwwLgYDVR0lAQH/BCQwIgYFKoNFBAMGClGC5EKDM5PeXzUGBi2CVyLNCQYFUTiB
akowGgYDVR0SBBMwEaQPMA0xCzAJBgNVBAYTAlVT
4. Copy the encoded blob, without any modifications, to a file.

1. Go to this directory: <server_root>/bin/cert/tools/
2. Enter this command: AtoB <input_file> <output_file>, substituting <input_file> with the path to the file that contains the base-64 encoded data in ASCII format (from Step 2) and <output_file> with the path to the file to write the base-64 encoded data in binary format.
3. Next, enter this command: dumpasn1 <ouput_file>, substituting <output_file> with the path to the file to that contains the base-64 encoded data in binary format. Your output should look similar to this:
   0 30   76: SEQUENCE {
   2 30   46:   SEQUENCE {
   4 06    3:     OBJECT IDENTIFIER extKeyUsage (2 5 29 37)
   9 01    1:     BOOLEAN TRUE
  12 04   36:     OCTET STRING
            :       30 22 06 05 2A 83 45 04 03 06 0A 51 82 E4 42 83
            :       33 93 DE 5F 35 06 06 2D 82 57 22 CD 09 06 05 51
            :       38 81 6A 4A
            :     }
  50 30   26:   SEQUENCE {
  52 06    3:     OBJECT IDENTIFIER issuerAltName (2 5 29 18)
  57 04   19:     OCTET STRING
            :       30 11 A4 0F 30 0D 31 0B 30 09 06 03 55 04 06 13
            :       02 55 53
            :     }
            :   }

0 warnings, 0 errors.

4. If the output doesn't appear right, repeat Step 1 through Step 3 to get the correct output.

Hardware Tokens

• The section "Step 2. Install the PKCS #11 Module" in Chapter 8, "Keys and Certificates" of Netscape Certificate Management System Administrator's Guide states that you can install a PKCS #11 module using Netscape Console only if the device vendor provided the corresponding DLLs in a JAR package. This limitation was present in Netscape Console 4.0, but not in Netscape Console 4.1. Certificate Management System 4.1 ships with Netscape Console 4.1 which allows you to install PKCS #11 modules irrespective of how the DLLs are packaged.

In Netscape Console 4.1, when you choose to add a PKCS #11 module, you are presented with a dialog box (shown below) that allows you to specify the path to the DLL or to the JAR file containing the DLL. You may choose either of the options.

If you choose JAR as your file type, you are required to provide the path to the JAR file that contains the DLLs. If you choose DLL as your file type, in addition to the path to the DLL you are also required to provide a name for the module you're attempting to install so as to help you identify it easily later.

The sample figure shows how you would install an nCipher token.

• When using the same hardware token for storing key pairs of multiple Certificate Manager instances, be sure to specify unique issuer DNs for the CA signing certificates. If you specify the same issuer DN for the CA signing certificates (you're asked to specify this when generating the certificate), the CMS installation wizard will fail to generate the certificate, and thus complete the installation process. [# 354993]

For example, assume you installed a CMS instance with a Certificate Manager and specified CN=myCA, O=Netscape, C=US as the issuer DN for the CA signing certificate. Next, you created another CMS instance with a Certificate Manager and attempted to generate a CA signing certificate with CN=myCA, O=Netscape, C=US as the issuer DN. The installation wizard will fail to generate the certificate; instead, it will display the following error message:
Token Error: import CA cert failure com.
netscape.jss.CryptoManager
$UserCertConflictException

• The default validity period of a self-signed Certificate Manager CA signing certificate is 2 years; the documentation incorrectly states that it is 1 year. When generating the certificate request (as a part of installation) you may change the validity period.   [# 356472]

• When naming a CMS instance, be sure to formulate the name using any combination of letters (aA to zZ), digits (0 to 9), an underscore (_), and a hyphen (-); other characters and spaces are not allowed. For example, you can type Netscape_root-CA as the instance name, but not Netscape root CA. [# 330806 and # 344584]

• When creating the internal database, which is an instance of Netscape Directory Server 4.1, the CMS installation wizard performs some LDAP operations by calling command-line tools, such as ldapmodify.  These tools are invoked by /bin/sh on Solaris. One of the command-line arguments to the tool is the bind password. If this password has any other character interpreted by the shell (for example, #, $, %, *, (, ), -, ', ", ?, \, |, ~, or `), the password gets mangled by the shell, causingldapmodify to fail (with an "Invalid Credentials" error), which in turn causes the wizard to fail.

To workaround the problem, use an alphanumeric password for the internal database. [# 357672]

• At the end of the installation wizard you will be asked to enroll for an agent certificate. If you go ahead and request the agent certificate, the Certificate Manager issues you a certificate with a validity period of one year, irrespective of the validity period of your CA certificate. The reason for this is as any other certificate request your very first agent certificate request gets subjected to the currently configured policy rules of the Certificate Manager. It is important to know that during CMS installation a few policy rules are automatically enabled with default settings. To find out more about these rules:

1. Login to Netscape Console.
2. Double-click the CMS instance of your interest.
3. In the navigation tree, click Certificate Manager.
4. Click Policies. The right pane lists the currently configured policy rules. To view current settings of a rule, select it and click Edit.

The default policy rule named DefaultValidityRule (which is based on the ValidityConstraints policy plug-in implementation) controls the validity period of all certificates issued by the Certificate Manager. By default, this rule is configured to issue certificates that are valid for a year (365 days), starting from the day they are issued. [# 357591]

If you want your agent certificate's validity period to be the same as that of your CA certificate, you must edit the DefaultValidityRule policy rule so that the server approves the validity period you want to request. The steps below explain how to get an agent certificate with the same validity as that of the CA certificate:
 
1. Edit the DefaultValidityRule policy rule:
1. Login to Netscape Console.
2. Double-click the CMS instance of your interest.
3. Login to open the CMS window.
4. In the navigation tree, click Certificate Manager.
5. Click Policies. The right pane lists the currently configured policy rules.
6. Select DefaultValidityRule and click Edit.
7. In the Policy Rule Editor, edit the value of the maxValidity parameter to the match the validity period, in days, of your CA certificate. Be sure to enter the correct number of days, starting today, the certificate should remain valid. For example, if your CA certificate is valid for 2 years (730 days) and it's 30 days since you've issued it, you want your agent certificate to be valid for the next 700 days. So, you should enter a number that is greater than 700.

By default, any validity requested in a certificate enrollment or renewal request cannot exceed beyond that of the expiration time specified in the CA's signing certificate. If the Certificate Manager (CA) finds 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. For example, if the CA signing certificate expires on June 10, 2004, any enrollment or renewal request with validity period beyond June 10, 2004 will have validity period truncated to end on June 10, 2004. (See how you can control this feature with the help of the enablePastCATime parameter in the configuration file.)
8. Click OK.
9. Click Refresh.
10. Restart the server.
2. Enroll for your very first agent certificate:
1. Open a browser window in the client that you want to use to access agent pages.
2. Access the agent page at this URL: https://<host_name>:<agent_SSL_port>/ca/adminEnroll.html
3. Enter the required information. When obtaining the very first agent certificate, it is essential that the user ID and password you enter in the enrollment form match exactly with the CMS privileged user ID and password you specified when you ran the installation program. The default value assigned to the CMS privileged user ID is admin.
4. Click Submit.
5. Follow the prompts and import the agent's certificate to your client's certificate database.
6. Go to the Security Preferences or Security Info dialog box and verify that the certificate is listed under Personal Certificates or Yours.
3. Change the DefaultValidityRule policy rule to its original configuration:
1. Go back to the CMS window and edit the DefaultValidityRule policy rule to suit your certificate validity period requirement.
2. Restart the server.

• If the configuration wizard terminates abnormally, attempts to restart it will generate a dialog box that says, "operation error: unable to start the daemon." To workaround this problem, remove the lock file, <server_root>/cert-<instance_id>/logs/daemon.lck. [# 347678]

• When installing a Registration Manager, the installation wizard does not present you with an appropriate screen for specifying whether you want to connect it to a Certificate Manager or to another Registration Manager. The wording on the screen suggests that the Registration Manager can only be connected to a Certificate Manager.

For example, assume that you are installing a Registration Manager (RA2) and want to chain it to another Registration Manager (RA1) that has already been installed and connected to a Certificate Manager (CA). When you run the installation wizard for RA2, you should have the opportunity to specify the host name and port number of RA1 so as to chain RA2 to RA1. However, the screen presented by the installation wizard suggests that you can connect RA2 to CA only. Note that the error is limited to the wordings on the screen only. You may use the input fields to enter values that correspond to a Certificate Manager or Registration Manager. In other words, you should ignore the on-screen wordings and enter the host name and port number of the subsystem -- either a Certificate Manager or another Registration Manager -- to which you want to connect the Registration Manager being installed. [# 351672]

• In the section entitled "Platform Requirements" in Chapter 2, "Default Demo Installation"  of Netscape Certificate Management System Installation and Deployment Guide, it is stated that "patch level 103640-12 or greater is required". The correct information is "Patch level 103640-12 or greater is required for Solaris 5.5.1 systems only".

To determine the patch level installed on your system, run this command: showrev -a
[# 355005]

• When installing Certificate Management system on a machine running Windows NT 4.0 with Service Pack 3.0 or 4.0, make sure that file system is NTFS; FAT file system will not work due to the restriction imposed by Netscape Directory Server 4.1.

• See the one listed in the Scalability/Sizing section.

• Internationalization is not fully supported in this release.

• When naming a job (instance), be sure to formulate the name using any combination of letters (aA to zZ), digits (0 to 9), an underscore (_), and a hyphen (-); other characters and spaces are not allowed. For example, you can type My_Job or MyJob as the name, but not My Job.

• Notification of rejection -- Chapter 13 of Netscape Certificate Management System Administrator's Guide introduces job scheduling and notifications and describes how to set up automated notification of certificate issuance. However, it doesn't give equivalent details regarding automated notification that a certificate request has been rejected.

As described in Chapter 13, the email notification that a certificate has been issued is based on a template file whose default name begins with certIssued. The CMS administrator can customize certain aspects of this template (such as the subject of the email message and the location and name of the template file) using the CMS window of Netscape Console. The administrator can customize the content of the message by changing the file itself.

Similarly, the email notification that a certificate has been rejected is based on a template file whose name begins with certRequestRejected. This template file must be located in the same directory as the certificate issuance template. Unlike the certificate issuance template, the basic filename of the certificate rejection template (certRequestRejected) cannot be changed. However, the file extension for the certRequestRejected file can be changed, as long as it exactly matches the file extension for the certificate issuance template file. For example, if the certificate issuance template file is named certIssued_CA.htm, the certRequestRejected file must be named certRequestRejected.htm. The HTML file extensions permitted are .htm, .html, .HTM, and .HTML. Template files with any other extension (or no extension) are treated as a text file.

Only two tokens are available for use in the certRequestRejected template: $InstanceID and $RequestID. There are no separate configuration parameters for this template.

• The section entitled "Notifications of Certificate Issuance to End Entities" in Chapter 13, "Job Scheduling and Notifications" of Netscape Certificate Management System Administrator's Guide says that the email address used in a request completed (certIssued) notifier is the email address in the certificate or the email specified in the requestor email field of a request. However, it doesn't make it clear exactly how an email is resolved. Note that email resolver first checks for the requestor email and if doesn't find one, it checks the email address in the subject name of the certificate. If neither is specified, the notification is sent to the email address specified in the From field, instead of the requestor, as an undeliverable notification. There'll also be a message to this effect in the logs. [# 352318]

• See # 331081 listed in the UI (Netscape Console/CMS Window) section.

• See the ones listed in the CRLs section.

• This version of Certificate Management System supports LDAP publishing with basic authentication and LDAP publishing over SSL with client authentication; LDAP publishing over SSL with basic authentication doesn't work. For detailed instructions on setting up LDAP publishing over SSL with client authentication, see the Troubleshooting Certificate Management System 4.1 document, which is at this URL: http://developer.iplanet.com/docs/manuals/cms.html

• If you've configured Certificate Management System for LDAP publishing and if the publishing directory has been stopped, the server logs the following message in its error and system logs:

Error publishing CRL MasterCRL: Cannot find a match in the LDAP server for certificate. netscape.ldap.LDAPException: unable to establish connection (52); DSA is unavailable.

Notice that the error message incorrectly says DSA is unavailable instead of  Directory Server is unavailable.

When the directory is down, if a Certificate Manager agent attempts to update the CRL published to the directory (by clicking the Update Revocation List button in the agent interface), he or she will see the same error message. [# 357015]

• The section entitled "Log Levels (Message Categories)" in Chapter 22, "Introduction to Logs" of Netscape Certificate Management System Administrator's Guide indicates that the default log levels for all the CMS logs -- audit, error, and system -- are set to level 3 (Failure). This is incorrect. Only the error and system log levels are set to 3; the audit log level is set to 1 (Informational) by default.

Similarly, the section "Logging to Windows NT Event Log" in Chapter 23, "Managing Logs" of Netscape Certificate Management System Administrator's Guide indicates that the default log level for the Windows NT event log that corresponds to the CMS audit log (parameter named logNTAudit.level) is set to 2 (Warning), instead it is set to to level 1 (Informational). [# 355832]

• The default value assigned to the flushInterval parameter for all three CMS logs is 5 seconds, not 300 seconds as indicated in section "Buffered Versus Unbuffered Logging" in Chapter 22, "Introduction to Logs" of Netscape Certificate Management System Administrator's Guide. [# 355832]

• When running Certificate Management System on a Windows NT system, if you don't configure the NT Event Log properly (see the section "Logging to Windows NT Event Log" in Chapter 23, "Managing Logs" of Netscape Certificate Management System Administrator's Guide), the event log will get full. When this happens, you'll see a dialog box stating that the application log file is full. If you see this dialog, you must clean up the application log immediately. [# 356836]

Here's what you should do:
1. From the Start menu on your desktop, select Programs, Administrative Tools (Common), and Event Viewer, in that order. This opens the Event Viewer window for the system.
2. From the Log menu and select Application (a checkmark to the left indicates it is selected).
3. From the Log menu, select Log Settings. This opens the Event Log Settings window.


4. Enter the appropriate values:
• Change Settings for. Make sure that the Application log is selected in this box.
• Maximum Log Size. Select a reasonable size so that the event log doesn't get full in a short period of time.
• Event Log Wrapping. Select the "Overwrite Events as Needed" option.
5. Click OK.
6. Close the Event Viewer window.

• The sections entitled "Command-Line Utilities" in Chapter 1, "Introduction to Certificate Management System" of Netscape Certificate Management Installation and Deployment Guide and "Summary of Command-Line Utilities" in Appendix A, "Command-Line Utilities" of Netscape Certificate Management System Administrator's Guide explain that the <server_root>/bin/cert/tools/migrate is an executable. Instead, it is a directory containing a series of subdirectories (bin/cert/tools/migrate/[AIX, HP-UX, Solaris, WINNT]) for the platform-specific migrate utilities. [# 356026]

After unpacking the CMS binaries (or after installing Certificate Management System), here's what you should do:

1. Copy the appropriate executable to the machine that hosts your Certificate Server 1.x.
2. As explained in Appendix A, "Migrating from Certificate Server 1.x " of Netscape Certificate Management Installation and Deployment Guide, run the utility to generate the three platform-independent files, database_modify.ldif, database_add.ldif, and keyscerts.dat.
3. Depending on your CMS 4.1 installation platform, edit these files as appropriate (add or remove Ctrl-M) following the guidelines outlined below.
4. Import the files into your CMS installation.

• Appendix A, "Migrating from Certificate Server 1.x " of Netscape Certificate Management Installation and Deployment Guide explains that the Migration Tool extracts the database contents (as stored in the Informix database) and certificate/key data (as stored in flat-file DBM databases) from Certificate Server 1.x and places the data in three platform-independent files that can be transferred by diskette, tape, or FTP to a Certificate Management System 4.1 installation area for import into the new system. However, the document does not explain that importing of the files exported from a Windows NT installation of Netscape Certificate Server 1.x into a Unix installation of Certificate Management System 4.1 (and vice versa) requires you to make certain modifications to the files in order for them to be successfully imported -- before importing the files that have been exported from a Windows NT installation of Certificate Server 1.x, you must strip the trailing Ctrl-M from all the lines in these files. Similarly, when importing files that have been exported from a Unix installation of Certificate Server 1.x into a Windows NT installation of Certificate Management System, you must make sure that all the lines in these files terminate with a Ctrl-M.

The information that follows explains the required modifications. Keep in mind that you must modify all the three files the Migrate Tool generates:
• database_modify.ldif
• database_add.ldif
• keyscerts.dat

For modifying the files, you may use a text editor or any suitable command-line utility, such as dos2unix. The steps below show how you can edit (using the "vi" editor) the files exported from a Windows NT installation of Certificate Server 1.x in order for them to be successfully imported into a Unix installation of Certificate Management System.

  1. Open one of the files in "vi".
  2. Start at the first line.
  3. Press the 'Esc' key.
  4. Press the following keys, in that order:

      ':' 'g' '/' 'Ctrl-V' 'Ctrl-M' '/' 's' '/' '/' '/' 'g'

     The on-screen information must resemble this:

   :g/^M/s///g

  5. Press the 'Enter' key.
  6. Verify that the Ctrl-M (^M) characters have been removed from all the lines.
  7. Save the file.
  8. Repeat the above steps for the remaining two files.
  9. Make sure that all the files are saved in the same directory.
10. Import the files to the Unix installation of Certificate Management System following the instructions in the Installation and Deployment Guide.

• Migration Tool fails to inform you of a failure to export data successfully -- If you encounter any Informix database-related problems/errors when exporting Certificate Server 1.x data into three platform independent files, be sure to quit the migration process, fix the Informix database-related error, and then rerun the tool again. Note that even when the tool encounters an error, it gives you the opportunity to continue with the process without giving any indication about its failure to export all the required information. You are informed of this failure later, after you have imported the data into a CMS installation and when you attempt to start Certificate Management System. [# 355928]

The sample shown below illustrates this behavior of the tool. The sample shows a data migration session with an Informix database related error followed by the migration tool's prompt (shown in bold) to continue with the process. If you choose to continue with the process (that is, you type 'y' at the prompt and press the 'Enter' key), the migration tool skips the "Server key password:" step and later informs you that it couldn't find the "Server-Key" in the ServerKey.db. Notice the last line of the sample where the tool informs you that it has completed migrating the keys and certificates (although it didn't give you an opportunity to enter the password for the SSL server key database and thus failed to migrate the SSL server key) and that the file named "keyscerts.dat" has been generated.

Now, if you import the migration files into the CMS installation and then attempt to start the server, it would fail to do so because it doesn't have the SSL server key.

Sample:

> root@oblivion:tools>./migrate
> certsrvroot=/export2/inst/ns-home-cert/cms-oblivion
> dbrootdir=/export/home/informix outputdir=/export2/cms-migrate
> database Name [cmsdb]:
> database login name [cmsdbusr]:
> database password:
>
> Starting Database migration...
> Connected to database!
> migrating certificate records...
> extracted 52 cert record(s)
> migrating last serial number...
> migrating Certificate Revocation List...
> migrate: warning: No entries were found in "t_iss_auth_prop", CRL
> migration aborted.
>
> Continue migration?[y|n]: y
>
> Enter the passwords used to protect server key data:
> Server key password:
> Signing key password:
> Select a Transport password to protect the private key material:
> Transport password:
> Verify Transport password:
>
> Starting Certs and Keys migration...
> Successfully Dumped Server Certificate Chain
> Successfully Dumped Signing Cert
> Unable to find  Server-Key in
> /export2/inst/ns-home-cert/cms-oblivion/config/ServerKey.db
> Probable password error
> Successfully dumped Signing Key
> Certs and Keys migration completed, keyscerts.dat file generated

• On AIX, the directory containing Informix must be located in /usr/informix (the default), or the migration tool will not function properly. A simple workaround on this platform would be for the administrator to make a symbolic link to the Informix installation, if it has not been installed at this location.

On Windows NT, the location of the Informix DLLs must be specified in the PATH environment variable. For example, if the Informix installation was c:\informix, then c:\informix\bin must be part of the path statement, or the migration tool will complain that it cannot find ISQLT07C.DLL and will not run.

• The configuration file, CMS.cfg, only supports Unix-style file separator, the forward slash (/). If MS file separator is required, you should use two backward slashes (\\) instead of one (\). [# 326875 and # 331495]

• The procedure for configuring CMS instances to listen to specific IP addresses in the section entitled "Specifying IP Addresses for CMS Instances" in Chapter 6, "Configuring Ports, Database, and SMTP Settings" of Netscape Certificate Management System Administrator's Guide incorrectly  tells you to add a parameter named 'listenaddr' to the configuration file. The correct name of the parameter is 'host' and it accepts either the IP address (for example, 197.1.137.98) or the host name/interface name (for example, cert.siroe.com) at its value. [# 348958]

The corrected procedure is as follows:

1. Stop the CMS instance.
2. Open the configuration file, CMS.cfg, in a text editor.
3. Add one or more of the following parameters as appropriate:
• For remote administration port, add this line: radm.https.host=
• For agent port, add this line: agentGateway.https.host=
• For end-entity HTTPS port, add this line: eeGateway.https.host=
• For end-entity HTTP port, add this line: eeGateway.http.host=

4. Add the IP address or the host name/interface name as the value for the parameter you just added. For example,
• If you entered the IP address as the value, the parameter would look similar to this: radm.https.host=197.1.137.98
• If you entered the host name as the value, the parameter would look similar to this: radm.https.host=cert.siroe.com

5. If necessary, repeat steps 3 and 4 for the other ports.
6. Save your changes, and close the configuration file.
7. Start the CMS instance.

• Limitation in ECXpert 2.x when using certificates issued by Certificate Management System 4.1 -- when you paste in a certificate issued by Certificate Management System into ECXpert 2.x, be sure to cut and paste the base-64 encoded certificate excluding the marker lines -----BEGIN CERTIFICATE----- and -----END CERTIFICATE-----; including the marker lines will result in an error. [# 356027]

• When using Apache web server with SSLEay, do not add in a challenge password. The challenge password results in illegal encoding in the resultant PKCS #10 certificate signing request (CSR) that is submitted to Certificate Management System.  In order to work-around this SSLEay problem, do not include a challenge password. [# 356465]

• Initial connection to Netscape Console with a 2048-bit RSA SSL server certificate is a bit longer than the one made with a 512 bit RSA SSL server certificate.

• You may encounter problems with Certificate Management System when using SSL server certificates that are issued by a public CA, if these certificates have Basic Constraints extension set in them. [# 356424]

• By default, any validity requested in a certificate enrollment or renewal request cannot exceed beyond that of the expiration time specified in the CA's signing certificate. If the Certificate Manager (CA) finds 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. For example, if the CA signing certificate expires on June 10, 2000, any enrollment or renewal request with validity period beyond June 10, 2000 will have validity period truncated to end on June 10, 2000. (In general, this is the safer thing to do for CA certificate renewal.)

However, you can override the default configuration by modifying the value of the enablePastCATime parameter in the configuration file, CMS.cfg. For example, if you set the value of the enablePastCATime to true (ca.enablePastCATime = true), the Certificate Manager will not truncate the validity period and issue the certificate with the validity period being requested.

This configuration variable is not exposed in the CMS window, and you must configure it manually by editing the configuration file. If you set the value of the enablePastCATime parameter to true, be sure to renew the CA's signing certificate with the same key before the certificate expires.

• You can configure the Certificate Manager and Registration Manager to check the revocation status of an agent's certificate the server receives during authentication; in this release, you cannot configure the Data Recovery Manager to check the revocation status of its agents' certificates. The configuration file includes parameters that enable you to specify whether the server should do the revocation checking and if it should, at what intervals. Note that the revocation status verification works for only those agent certificates that have been issued by the Certificate Manager. [# 357064]

The set of configuration parameters pertaining to this feature of the server are as follows:

auths.revocationChecking.bufferSize=5
auths.revocationChecking.ca=ca
auths.revocationChecking.enabled=true
auths.revocationChecking.ra=ra
auths.revocationChecking.validityInterval=28800

Parameter name	Description
revocationChecking.bufferSize	Specifies the total number of last-checked certificates the server should maintain in its cache. For example, if you configure the buffer size to be 2, the server retains the last two certificates it checked in its cache. By default, the server caches the last 5 certificates.
revocationChecking.<subsystem>	Specifies the name of the CMS instance.  <subsystem> indicates whether the subsystem is a Certificate Manager (ca) or Registration Manager (ra).
revocationChecking.enabled	Specifies whether revocation checking is to be is enabled or disabled. To enable the feature, enter true; to disable the feature, enter false. By default, the feature is enabled.
revocationChecking.validityInterval	Specifies how long the cached certificates are considered valid (you can tune the revocation refresh interval). The validity period must be specified in seconds. Be judicious when choosing the interval, especially when configuring a Registration Manager. For example, if you configure the validity period to be 60 seconds, the server discards the certificates in its cache every minute and attempts to retrieve them from their source -- the Certificate Manager uses its internal database to retrieve and verify the revocation status of the certificates whereas the Registration Manager retrieves the certificates from its own internal database and then requests the Certificate Manager for the revocation status of these certificates. The default validity period is 28800 seconds (8 hours).

• To improve performance under high load on Solaris we recommend that you do the following:

1. Install Solaris patches 103582 and 103630; these patches include various TCP/IP performance/stability related fixes.
2. Increase the number of threads available listening on the end-entity port by adding the following to the configuration file (CMS.cfg):
eeGateway.http.backlog=30
eeGateway.http.maxThreads=40
eeGateway.https.backlog=30
eeGateway.https.maxThreads=40
3. If you increase the number of threads available listening on the end-entity port, you must also increase the number of per-process file descriptors. By default, this limit is 64. Check your system by typing: 'sysdef'. Note that the value reported is in hex. To increase the number of file descriptors (each thread may use at least one, maybe two file descriptors; also remember that about 30 are used by Certificate Management System for other purposes), edit the /etc/system file, inserting the following lines:
set rlim_fd_max=1024
set rlim_fd_cur=256
4. Reboot the system. [# 345598]

• Policies for the following extensions are not supported in this release:
• Extended Key Usage
• Name Constraints
• Policy Constraints

• When naming a policy instance (or rule), be sure to formulate the name using any combination of letters (aA to zZ), digits (0 to 9), an underscore (_), and a hyphen (-); other characters and spaces are not allowed. For example, you can type My_Policy_Rule or MyPolicyRule as the instance name, but not My Policy Rule.

• Table 15.2 (which lists the attributes that you may use to formulate the predicate expression for policy rules) in the section "Attributes for Predicates" in Chapter 15, "Introduction to Policy" of Netscape Certificate Management System Administrator's Guide incorrectly states that the CertType attribute value for a router certificate request is Cisco-router. Instead, it is CEP-Request. For example, you can formulate a predicate expression such as certType!=CEP-Request or certType==CEP-Request.

• The "DSA Key Constraints Policy" explained in Chapter 15, "Introduction to Policy" of Netscape Certificate Management System Administrator's Guide  does not work in this release; the plug-in module shows up in the console UI and in the configuration file, but it doesn't work. [# 371027]

• The "Validity Constraints Policy" explained in Chapter 15, "Introduction to Policy" of Netscape Certificate Management System Administrator's Guide does not check the lag time in certificate requests. Users may be able to make CRMF requests where they request a validity with 'notBefore' in the past. [# 344786]

• The "Key Usage Extension Policy" explained in Chapter 15, "Introduction to Policy" of Netscape Certificate Management System Administrator's Guide includes a new configuration parameter named setDefaultBits, which allows you to specify whether to set a default key usage extension on certificates being issued. The parameter accepts either true or false as its value.

• If you set the value of this parameter to true and if no bits are requested from the HTTP input, the server adds a default key usage extension to certificates. The default bits set include the following:
• digital signature (bit 0)
• key encipherment (bit 2)
• data encipherment (bit 3)

• If you set the value of this parameter to false and if no bits are requested from the HTTP input, the server does not add the extension to certificates. [# 350797]

• The "Netscape Certificate Type Extension Policy" explained in Chapter 15, "Introduction to Policy" of Netscape Certificate Management System Administrator's Guide includes a new configuration parameter named setDefaultBits, which allows you to specify whether to set a default Netscape certificate type extension on certificates being issued. The parameter accepts either true or false as its value.

• If you set the value of this parameter to true and if no bits are requested from the HTTP input, the server adds a default Netscape certificate type extension to certificates. The default bits set include the following:
• ssl client (bit 0)
• email (bit 2)

• If you set the value of this parameter to false and if no bits are requested from the HTTP input, the server does not add the extension to certificates. [# 350797]

• The section entitled "Constraints-Specific Policy Plug-in Modules" in Chapter 15, "Introduction to Policy" of Netscape Certificate Management System Administrator's Guide does not provide information about the following policy plug-in modules supported by the server.

Additional policy plug-in modules supported by the server

Policy plug-in module name	Description
RenewalConstraints	This policy enables you to configure the server to allow or reject requests for renewal of expired certificates.
RevocationConstraints	This policy enables you to configure the server to allow or reject requests for revocation of expired certificates.
SigningAlgorithmConstraints	The policy allows you to specify the signature algorithm to be used by the Certificate Manager to sign certificates. The Certificate Manager supports  MD2 with RSA, MD5 with RSA, and SHA-1 with RSA, if its signing key is RSA. SHA-1 with DSA, if its signing key is DSA. When a Certificate Manager digitally signs a message, it generates a compressed version of the message called a message digest. Some of the algorithms used to produce this digest include MD5 and SHA-1 (Secure Hash Algorithm). MD5 generates a 128-bit message digest. Most existing software applications that handle certificates only support MD5. SHA-1 generates a 160-bit message digest. Some software applications do not yet support the SHA-1 algorithm. For example, Netscape Navigator 3.0 (or higher) and Enterprise Server 2.01 (or higher) support SHA-1; previous versions of these applications do not support SHA-1. Note that by default no rule is created for this policy. If required, you may create an instance of this policy manually through the Console. [# 355829]
UniqueSubjectName	This policy enables you to configure the server to not issue multiple certificates with the same subject names; however, you can configure this policy to allow multiple certificates with the same subject name if the key usages are different.

The configuration parameters pertaining to the SigningAlgorithmConstraints policy plug-in implementation are listed in the table below:

Configuration parameters for the SigningAlgorithmConstraints policy

Parameter name	Description
algorithms	Specifies the signature algorithm the Certificate Manager should use to sign certificates. Permissible values include the following: If the CA signing key type is RSA, then you may enter one or more of the following; use commas to separate different values: MD2withRSA MD5withRSA SHA1withRSA If the CA signing key type is DSA, then you should enter this: SHA1withDSA
enable	Specifies whether the rule is enabled or disabled. To enable the rule, enter true; to disable the rule, enter false. By default, the rule is enabled.
predicate	Specifies the predicate expression for this rule. If you want this rule to be applied to all certificate requests, leave the field blank. By default, the rule is applied to all certificate requests.

The configuration parameters pertaining to both the RenewalConstraints and RevocationConstraints policy plug-in implementations are listed in the table below. [# 351754]

Configuration parameters for the RenewalConstraints and RevocationConstraints policies

Parameter name	Description
enable	Specifies whether the rule is enabled or disabled. To enable the rule, enter true; to disable the rule, enter false. By default, the rule is enabled.
allowExpiredCerts	Specifies whether to allow or prevent renewal or revocation of expired certificates. To allow renewal or revocation of expired certificates, enter true. To prevent, enter false. The default value is true, that is, the expired certificates are allowed for renewal and revocation.
predicate	Specifies the predicate expression for this rule. If you want this rule to be applied to all certificate renewal or revocation requests, leave the field blank. By default, the rule is applied to all certificate renewal or revocation requests.

The configuration parameters pertaining to the UniqueSubjectName policy plug-in implementation are listed in the table below. [# 354792]
Note that whenever you change any of the parameter values, be sure to restart the server for the new configuration to take effect; the server doesn't prompt you to do so. [# 356999]

Configuration parameters for the UniqueSubjectName policy

Parameter name	Description
enablePreAgentApprovalChecking	Specifies whether the request must be checked for the subject name uniqueness on submission by the user, before the request gets queued for agent approval. Enter true if you want the policy to be applied to the request right after it's submission by the user. Enter false if you want the policy to be applied to the request after an agent approves it for issuance.
enableKeyUsageExtensionChecking	Specifies whether the certificate request must be checked for the Key Usage extension. Note that the  policy can check the certificate request for the Key Usage extension only if you set the enablePreAgentApprovalChecking parameter value to false -- the extensions are set on the request after agent approval, so this checking can be done after an agent approves the request. Permissible values for this parameter include either true or true. If you set the value to true, the policy checks the internal database for certificates that have the same subject name as the one specified in the request. For each certificate that has the matching subject name, the policy compares the Key Usage extension of the certificate to the one specified in the request. If the extension finds a certificate that has the same subject name and Key Usage extension, the request is rejected. Otherwise, the request is approved. (This is suitable if you want to have multiple certificates with same subject names but for different purposes -- such as signing, encrypting, etc.) If you set the value to false, the policy does not compare the Key Usage extension in the request with the ones set in the existing certificates that have the same subject name; it simply rejects the request.
enable	Specifies whether the rule is enabled or disabled. To enable the rule, enter true; to disable the rule, enter false. By default, the rule is disabled. If you enable the rule and if the Key Usage extension comparison is to be done, be sure to order (using the Reorder button) the policy so that it gets applied after the Key Usage extension policy.
predicate	Specifies the predicate expression for this rule. If you want this rule to be applied to all certificate enrollment requests, leave the field blank. By default, the rule is applied to all certificate enrollment requests.

• See the ones listed in the CRLs section.

• The section "Subject Alternate Name Extension" Policy in Chapter 15, "Introduction to Policy" of Netscape Certificate Management System Administrator's Guide states that if the policy is enabled, the server checks the certificate request for a mail attribute, and if it is present, adds the Subject Alternate Name extension to the certificate being issued. Both the built-in directory-based authentication modules can obtain a mail attribute from the authentication directory and set that attribute in the certificate request. For more information on the mail attribute, see the description for the ldapAttributes parameter in Table 9.1 and Table 9.2.

The correct information is as follows:
If you enable the Subject Alternate Name extension policy, the server checks the certificate request for a mail or mailalternateaddress attribute, which is set by the ldapStringAttributes parameter defined in both the directory- and PIN-based authentication modules. If the server finds a mail or mailalternateaddress attribute, it adds the Subject Alternate Name extension to the certificate being issued. For more information on setting the mail or mailalternateaddress attribute, see the description for the ldapStringAttributes parameter.

To add the Subject Alternate Name extension to certificates, here's what you should do:

Step 1. Ensure that the ldapStringAttributes parameter in the authentication instance is set to mail. You can do this either from the console or by directly editing the CMS.cfg file.
To do this from the console:

1. Login to Netscape Console.
2. Open the CMS window for the CMS instance of your interest.
3. In the navigation tree, click Authentication.
4. In the right pane, select the appropriate authentication instance, and click Edit.
• If you're using the directory-based enrollment instance with the default instance name, select UserDirEnrollment.
• If you're using the PIN-based enrollment/authentication instance with the default instance name, select PinDirEnrollment.
5. Set the value of the ldapStringAttributes parameter to mail.
6. Click OK.
To do this by modifying the CMS.cfg file:
1. Open the CMS.cfg file in a text editor.
2. Locate the ldapStringAttributes parameter and set its value to mail; this enables the server to look up the LDAP attribute named mail from the authentication directory (when the user gets authenticated) and store its value in the certificate request where it can be later accessed by the Subject Alternate Name extension policy rule.
• If you're using the directory-based enrollment instance with the default instance name, edit the following parameter: UserDirEnrollment.ldapStringAttributes=mail
• If you're using the PIN-based enrollment/authentication instance with the default instance name, edit the following parameter: PinDirEnrollment.ldapStringAttributes=mail
3. Save your changes and close the file.
Step 2. Ensure that the Subject Alternate Name extension policy is enabled.
1. Open the CMS window.
2. In the navigation tree, choose the subsystem (for example, Certificate Manager) that will use the Subject Alternate Name extension policy.
3. Click Policies.
4. In the right pane, select the Policy Plugin Registration tab.
5. Click Register and specify information as appropriate:
• Plugin name. Type SubjAltNameExt (the name of the plug-in).
• Class name. Type com.netscape.certsrv.policy.SubjAltNameExt (the full name of the class for this plug-in -- that is, the path to the implementing Java class).
6. Click OK.
7. Click Policy Rules Management tab.
8. Click Add.
9. Select SubjAltNameExt and click Next.
10. In the Policy Rule ID field, enter an appropriate name for the rule.
11. Set the enable parameter to true.
12. Set the appropriate predicate expression, only if the extension is to be added to specific certificates. Leave the field blank if the extension is to be added to all certificates.
13. Click OK.
Step 3. Ensure that the S/MIME attribute is present in the enrollment form.
1. Open the enrollment form that corresponds to the authentication instance you updated in Step1.
• If you're using the default directory-based enrollment form, open the following file: <server_root>/cert-<instance_id>/web/ee/DirUserEnroll.html
• If you're using the default PIN-based enrollment form, open the following file: <server_root>/cert-<instance_id>/web/ee/DirPinUserEnroll.html
2. Locate the HTTP input variables and add the following line: <input type="HIDDEN" name="SMIME" value=true>
3. Save your changes and close the file.

• If the remote Registration Manager is not set up correctly to work with the Certificate Manager, an unclear HTTP message results. Check to make sure that the configuration for the remote Registration Manager is set up correctly.

• The Registration Manager does not yet support the CRS/CEP enrollment; all router enrollment requests must be made through the Certificate Manager. [# 341389]

• See # 351672 in the Installation section.

• See # 355937 in the Enrollment section.

• When you renew any of the CMS certificates -- Certificate Manager's CA signing certificate, Registration Manager's signing certificate, Data Recovery Manager's transport certificate, and SSL server certificates -- using the Certificate Setup Wizard available within the CMS window, the wizard saves the old certificate (in its base-64 encoded format) to a text file under the configuration directory located at:

<server_root>/cert-<instance_id>/config/

<instance_id> specifies the CMS instance in which the corresponding subsystem is installed.

The name of the text file varies depending on the certificate you choose for renewal. If you choose to renew

• the Certificate Manager's CA signing certificate, it will be saved to a file named prevCACert.txt.<timestamp>
• the Registration Manager's signing certificate, it will be saved to a file named prevRACert.txt.<timestamp>
• the Data Recovery Manager's transport certificate, it will be saved to a file named prevKRACert.txt.<timestamp>
• an SSL server certificate, it will be saved to a file named prevSSLCert.txt.<timestamp>

Note that the wizard deletes the old certificate from the server's certificate database and adds the renewed certificate to the database, so that the server is able to use the renewed certificate upon restart. This feature restricts you to set the value of the 'notBefore' attribute of the renewed certificate to either the current time or any time in the past, but not in the future.

If you set the validity period of the renewed certificate to begin on a future date and time, the server fails to use the certificate for its intended purposes. If this happens, you may either reinstall the old certificate (saved to the text file mentioned above) or renew the certificate again with an appropriate validity period. [# 353749]

• After you renew any of the CMS certificates -- Certificate Manager's CA signing certificate, Registration Manager's signing certificate, Data Recovery Manager's transport certificate, and SSL server certificates -- using the Certificate Setup Wizard, you must restart the server. [# 355726]

• This release does not support the cancel request operation.

Samples and SDKs

The correct location for CMS SDK and sample code is as follows:

• If you downloaded the CMS binaries from the web site, you will find the CMS_SDK directory where you unpacked/unzipped the binaries (in the same directory in which the setup program is located).
• If you installed Certificate Management System from a CD, check the CD for the CMS_SDK directory.

• As explained in the section entitled "Internal Database" in Chapter 6, "Configuring Ports, Database, and SMTP Settings" of Netscape Certificate Management System Administrator's Guide, Certificate Management System uses Netscape Directory Server 4.1 as its internal database for storing certificates and related information. We noticed that when you issue approximately 500,000 certificates, the file size of the internal database exceeds 2G -- in other words, to support 500,000 or more certificates, you'll need a directory database that is more than 2G in size.

If you plan on issuing 500,000 or more certificates per CA, make sure to install the Certificate Manager on a system that supports files greater than 2G in size:

• Windows NT supports file systems that contain files greater than 2G in size.
• Solaris versions 2.6 and later support file systems that contain files greater than 2G in size; these versions support a 64-bit file system (the earlier versions support a 32-bit file system).

• Searching for certificates is slow if the search criteria include a validity period and if there are many tens of thousands of certificates in the internal database.

• The 'Stop' operation stops the server without checking the password that is passed from the Console.

• The 'Start' operation fails when passed an incorrect password at startup -- when you attempt to start the server with a wrong password, the server does not prompt that the password you've entered is incorrect.

• Certificate Management System doesn't prompt you to supply the single sign-on password when you make an attempt to stop the server from the Windows NT service panel.

• When installing a certificate in the Console using X windows, you cannot simply highlight and drop the base-64 encoded certificate into the text box or field. Instead, you must explicitly cut the base-64 encoded certificate from one application (such as a text editor or web browser) and paste into the text box of the console. [# 327841]

• When you view a privileged user's certificate in the Console, the issuer DN appears before the subject name, pushing the subject DN past the edge of the window. This requires you to resize the window in order to view the subject DN. [# 329152 and # 345105]

• In the Console page for setting up LDAP publishing, there are input fields for entering values for the DNComps, filterComps, and baseDN parameters. Although value for either DNComps or baseDN is required, the UI gives the impression that values must be entered in both the fields. [# 331081]

• The Object menu in the Console has an empty entry, causing a tiny drop down menu box. [# 343733]

• If a DN (either issuer DN or subject DN) contains special characters defined in RFC-1779, the characters will be automatically prefixed with a backward slash (\) upon displaying. This slash may give you the wrong impression that a slash character is included in the DN, and it is not consistent with the behavior of Communicator that shows no slash character in such case. [# 351774]

• The Certificate Setup Wizard, when used to request a Registration Manager signing certificate, incorrectly states that you should "paste the request to the CA's server enrollment form". Instead, it should state that "paste the request to the Registration Manager enrollment form provided in the CA's end-entity interface". [# 356680]

• The Certificate Database Management window accessible from within the CMS window lists the certificates stored in the certificate database of the selected CMS instance. Note that in this release, the list includes only CA certificates and none of the other certificates, such as the SSL server certificate, installed in the database. Later releases will permit viewing all certificates. Because of this, you cannot view, delete, or untrust any of the non-CA certificates from the Certificate Database Management window. Instead, you must use the "Certificate Database Tool" (certutil), which is described in Appendix D of Netscape Certificate Management System Administrator's Guide.

For information on accessing the Certificate Database Management window and tasks you can accomplish from this window, see the section entitled "Managing the Certificate Database" in Chapter 8, "Keys and Certificates" of Netscape Certificate Management System Administrator's Guide.

• See also the ones listed under Starting/Stopping the Server.

When uninstalling Certificate Management System, if you uninstall Certificate Management System only, the Directory Server (called the configuration directory) retains the entry for the Certificate Management System you uninstalled.  Before installing Certificate Management System again, you must delete the entry (that corresponds to the Certificate Management System you uninstalled) from the Directory Server.  There are two ways to do this.

• If the Directory Server used by Certificate Management System was not installed as part of the CMS installation and contains information that is needed for other operations (for example, operations of other servers), then the recommended method is to access the database and delete the CMS object.
• If the Directory Server used by Certificate Management System was installed as part of the CMS installation and the information in the directory is no longer needed, then the Directory Server may be removed.  To remove the Directory Server, go to the CMS root directory and remove the directory and it's contents. Note that the directory name has the following default format: slapd-<uninstalled_CMS_name>

---

Contact Information

If you need further assistance or information about Certificate Management System, please contact technical support at http://help.netscape.com/.
You may also contact us through our newsgroup for support, questions, answers, and the latest information:

snews://secnews.netscape.com/netscape.dev.certificate

You might also find it useful to subscribe to the following newsgroups, where security-related topics are discussed:

snews://secnews.netscape.com/netscape.dev.ssl
snews://secnews.netscape.com/netscape.dev.security

When reporting problems, please include the following:

• The Certificate Management System release number.
• The machine type and operating system version.
• Specific description of the problem.