Netscape Certificate Management System 4.1
Last updated on October 26, 1999
These release notes contain important information about Netscape Certificate
Management System, version 4.1. Please read these notes before using the
product.
Use of this product is subject to the terms detailed in the license
agreement accompanying it.
Contents
CMS Documentation
Software/Hardware Requirements
Packages Used
Installation Procedure
Notes on Features
Known Bugs/Issues for
4.1 Release
CMS Documentation
You can find CMS documentation in the directory named Docs at
the top level of the CD. For installation instructions, see Netscape
Certificate Management System Installation and Deployment Guide, available
as a PDF file at
Docs/cs40_dep.pdf. For a summary of the other
CMS documentation that is available prior to installation, see Docs/docs_readme.html.
After you run the setup script as described under Installation
Procedure below, see <server_root>/manual/en/cert/manual/index.html
for a complete list of the documentation installed with the product.
If you are working with files you have downloaded, 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/en/cert/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://home.netscape.com/eng/server/cms/
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.
Packages Used
Administration Server, version 4.1
Directory Server, version 4.1
Built with NSS, version 2.6
Installation Procedure
For detailed installation instructions, see Netscape Certificate Management
System Installation and Deployment Guide, available as a PDF file at
Docs/cs40_dep.pdf.
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.
If you wish to install a separate stand-alone version of Netscape Console
for any reason, you can download it from this site: http://home.netscape.com/eng/server/console/4.1/
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, check this site: http://home.netscape.com/eng/server/cms/
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
This section lists various bugs and known issues and provides workarounds
for some of them.
Administration Server
-
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]
Authentication
-
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.
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=acme.org
LDAP attributes: cn: Jesse James
LDAP attributes: mail: jjames@acme.org
The subject name formulated will be as follows:
E=jjames@acme.org, CN=Jesse James, OU=people, O=acme.org, 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=acme.org
LDAP attributes: cn: Jesse James
LDAP attributes: mail: jjames@acme.org
The subject name formulated will be as follows:
E=jjames@acme.org, CN=Jesse James, OU=people, O=acme.org, 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=acme.org
LDAP attributes: cn: Jesse James
LDAP attributes: mail: jjames@acme.org
The subject name formulated will be as follows:
CN=Jesse James, OU=IS+OU=people, O=acme.org, 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"
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=acme,
org
LDAP attributes: cn: Jesse James
LDAP attributes: mail: jjames@acme.org
The subject name formulated will be as follows:
CN=Jesse James, OU=people+OU=IS, O="acme \, org", 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.
-
Create a user entry for the PIN manager.
-
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")
(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";
)
-
Put the above ACI in a text file called aci.ldif.
-
Copy the file to this directory: <server_root>/shared/bin
-
Open a command window.
-
Go to this directory: <server_root>/shared/bin
-
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
-
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:
-
Create an instance for the UidPwdPinDirAuth plug-in.
-
Login to Netscape Console.
-
Login to CMS window.
-
In the navigation tree, click Authentication.
-
In the right pane, click Add.
-
Choose UidPwdPinDirAuth and click Next.
-
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.
-
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.
-
Make sure to set the removePin argument to false.
-
Next, stop the server.
-
Click the Tasks tab.
-
Click Stop the Server.
-
Edit the configuration file.
-
Go to this directory: <server_root>/cert-<instance_id>/config/
-
Open the CMS configuration file (CMS.cfg) in an editor.
-
Locate this line: auth.instance.PinDirEnrollment.ldap.removePin=false
-
Change the value of the removePin argument from false
to true.
-
Start the server from the command line. This is a must.
-
Open a command window.
-
Go to this directory: <server_root>/cert-<instance_id>
-
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]
-
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. |
Browser
-
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.
CEP Support
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://www.netscape.com/eng/server/cms/41/technotes/cep/cep_setup.html
See # 341389 in the Remote Registration
Manager section.
CRLs
-
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
|
|
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.
Directory Server
-
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]
DSA
-
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:
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.
Enrollment
-
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.
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]
Enterprise Server
-
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
The section Step
6. Specify Extensions in Chapter 8, "Keys and Certificates" of Netscape
Certificate Management System Administrator's Guide specifies that
you can add a custom extension to any of the CMS certificates (such as
the CA signing and SSL server certificates) by adding the extension in
MIME-64 DER encoded format in the text area of the Certificate Setup Wizard
screen when requesting a certificate. The text field provided for pasting
the extension in general accepts a single extension, and the documentation
doesn't explain how you can add multiple extensions to the request. [#
348097]
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:
-
Note the file paths to the files that contain the programs for extensions.
-
Open a command window.
-
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
-
Copy the encoded blob, without any modifications, to a file.
Step 3. Verify that the extensions are joined correctly before adding
them to a certificate request. To do this, first you'll need to convert
the binary data to ASCII format using the AtoB utility and then
verify the binary data by dumping the contents of the base-64 encoded blob
using the dumpasn1 utility. For information on the AtoB
utility see
ASCII
to Binary Tool and for the dumpasn1 utility see dumpasn1
Tool; both the utilities are explained in Appendix C, Command-Line
Utilities of Netscape Certificate Management System Administrator's
Guide.
Here's how you would do this verification:
-
Go to this directory: <server_root>/bin/cert/tools/
-
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.
-
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.
-
If the output doesn't appear right, repeat Step 1 through Step 3 to get
the correct output.
Step 4. Copy the base-64 encoded blob in Step 2 (the output generated
by the ExtJoiner) to the wizard screen and generate the certificate or
the certificate signing request (CSR), if submitting the request to another
CA.
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
Installation
-
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:
-
Login to Netscape Console.
-
Double-click the CMS instance of your interest.
-
In the navigation tree, click Certificate Manager.
-
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:
-
Edit the DefaultValidityRule policy rule:
-
Login to Netscape Console.
-
Double-click the CMS instance of your interest.
-
Login to open the CMS window.
-
In the navigation tree, click Certificate Manager.
-
Click Policies. The right pane lists the currently configured policy rules.
-
Select DefaultValidityRule and click Edit.
-
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.)
-
Click OK.
-
Click Refresh.
-
Restart the server.
-
Enroll for your very first agent certificate:
-
Open a browser window in the client that you want to use to access agent
pages.
-
Access the agent page at this URL: https://<host_name>:<agent_SSL_port>/ca/adminEnroll.html
-
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.
-
Click Submit.
-
Follow the prompts and import the agent's certificate to your client's
certificate database.
-
Go to the Security Preferences or Security Info dialog box and verify that
the certificate is listed under Personal Certificates or Yours.
-
Change the DefaultValidityRule policy rule to its original configuration:
-
Go back to the CMS window and edit the DefaultValidityRule policy
rule to suit your certificate validity period requirement.
-
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.
Internationalization
Support
-
Internationalization is not fully supported in this release.
Job Scheduling/Notification
-
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]
LDAP Publishing
-
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://home.netscape.com/eng/server/cms/41/technotes/troubleshooting/trbl_doc.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]
Logging
-
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:
-
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.
-
From the Log menu and select Application (a checkmark to the left indicates
it is selected).
-
From the Log menu, select Log Settings. This opens the Event Log Settings
window.
-
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.
-
Click OK.
-
Close the Event Viewer window.
Migration Tool
-
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:
-
Copy the appropriate executable to the machine that hosts your Certificate
Server 1.x.
-
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.
-
Depending on your CMS 4.1 installation platform, edit these files as appropriate
(add or remove Ctrl-M) following the guidelines outlined below.
-
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:
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.
> 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.
Miscellaneous
-
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.netscape.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.netscape.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). |
Performance
-
To improve performance under high load on Solaris we recommend that you
do the following:
-
Install Solaris patches 103582 and 103630; these patches include various
TCP/IP performance/stability related fixes.
-
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
-
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
-
Reboot the system. [# 345598]
Policies
-
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 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:
-
Login to Netscape Console.
-
Open the CMS window for the CMS instance of your interest.
-
In the navigation tree, click Authentication.
-
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.
-
Set the value of the ldapStringAttributes parameter to
mail.
-
Click OK.
To do this by modifying the CMS.cfg file:
-
Open the CMS.cfg file in a text editor.
-
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
-
Save your changes and close the file.
Step 2. Ensure that the Subject Alternate Name extension policy
is enabled.
-
Open the CMS window.
-
In the navigation tree, choose the subsystem (for example, Certificate
Manager) that will use the Subject Alternate Name extension policy.
-
Click Policies.
-
In the right pane, select the Policy Plugin Registration tab.
-
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).
-
Click OK.
-
Click Policy Rules Management tab.
-
Click Add.
-
Select SubjAltNameExt and click Next.
-
In the Policy Rule ID field, enter an appropriate name for the rule.
-
Set the enable parameter to true.
-
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.
-
Click OK.
Step 3. Ensure that the S/MIME attribute is present in
the enrollment form.
-
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
-
Locate the HTTP input variables and add the following line: <input
type="HIDDEN" name="SMIME" value=true>
-
Save your changes and close the file.
Remote Registration
Manager
-
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]
Renewal of CMS
Certificates
-
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]
Request Queue Processing
-
This release does not support the cancel request operation.
Samples and SDKs
The documentation incorrectly tells you to check the <server_root>/bin/cert/samples/
directory for CMS samples. It also mentions that you can download CMS samples
and SDK from the http://home.netscape.com/eng/server/cms/ site.
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.
Scalability/Sizing
-
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
-
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.
Starting/Stopping
the Server
-
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.
UI (Netscape
Console/CMS Window)
-
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.
© Copyright 1999 Netscape Communications
Corporation. All Rights Reserved.