Netscape Signing Tool 1.x and Communicator 4.x are designed to read only the cert7.db files used by Communicator 4.x. If it happens that a certificate gets downloaded with Navigator 3.x after Communicator 4.x was installed and run, that certificate is recorded in a database of the older (3.x) format. While Communicator does automatically convert Navigator's cert5.db and key.db databases to the cert7.db and key3.db formats the first time it runs, it does not do so again.

To get a certificate into the new database from an old one requires forcing Communicator to reinitialize its cert7.db file as it does at first run-time. This requires that the certificates in the current cert7.db file be exported for later re- importing.

1. Click the Security Info button on the Communicator toolbar.
2. Click Yours under Certificates in the left panel, and select a certificate to export.
3. Click Export and save a PKCS #12 copy of the certificate to a safe location (if no copy already exists).
4. Repeat steps 2 and 3 for each certificate present.
5. Exit Communicator completely.
6. Move the cert7.db and key3.db files from your user profile directory to a backup directory. This is a safety measure: these files shouldn't be needed again. Once the following steps are successfully completed, and you have used signtool -l to verify that the upgraded cert7.db file has the right certificates, you can discard these backup copies.
7. Copy Navigator's cert5.db and key.db files to your Communicator user-profile directory.
8. Restart Communicator. It automatically upgrades the older database files, including their contents.
9. Click the Security Info button on the Communicator toolbar, then click Yours under Certificates in the left panel.
10. Click Import a Certificate and give the database password.
11. Select a certificate file to open and give the certificate's password.
12. Repeat steps 9 and 10 for each certificate to be re-imported.

Netscape Signing Tool 1.x reads the cert7.db files used by Communicator 4.x. Normally, cert7.db files record a certificate's complete certificate chain information using the PKCS #7 cryptographic message-syntax standard. However, Navigator 3.x wasn't designed to properly use this standard (it wasn't in wide use yet). Therefore, certificates used by Communicator 4.x that were originally imported with Navigator 3.x may not have all the certificate chain information required for object signing.

In the case of VeriSign Class 2 or Class 3 certificates, the missing portion of the chain is the intermediate node, since the root is provided with Communicator by default and the leaf is included in the existing certificate information. To get the intermediate portion, use Communicator 4.x and click these links for VeriSign Class 2 or VeriSign Class 3 certificate authority updates.

Communicator 4.05 (and only that version) has a bug that makes it sensitive to the case of the JAR manifest's filename as stored in the META-INF directory. Version 4.05 requires the filename to be all lowercase. Although the JAR specification calls for case insensitivity and the Netscape Signing Tool does generate a lowercase filename, an uppercase filename can appear if another tool is used to create the JAR, or case translation occurs on the Windows platform.

This problem can be repaired by re-signing the JAR with the Netscape Signing Tool, or by unzipping the file and changing MANIFEST.MF to manifest.mf.

For convenience, users may want to shorten the nicknames of some of the certificates they use. While certificates cannot be renamed directly, it may be possible to replace them and give the replacement a new name.

Note that this process can present a risk because it requires the user to delete a certificate before replacing it, and if the replacement fails and there is no backup certificate, the certificate is lost.

1. Click the Security Info button on Communicator's toolbar.
2. Click Yours under Certificates and select a certificate to rename.
3. Click Export and save a PKCS #12 copy of the certificate to a safe location (if no copy already exists). This copy is needed if replacement fails.
4. Click Delete and remove the certificate from the certificate database. Note that the certificate's corresponding private key isn't deleted, just the certificate itself.
5. Retrieve the certificate again from the Certificate Authority. The specific procedure for doing this depends on the Certificate Authority being used. Be very sure that the replacement is the correct one.
6. Enter a new name for the certificate when downloading it.

Note: The Export and Import buttons in the Security Info dialog box can't be used to change certificate nicknames. These functions can affect only a certificate's exported PKCS #12 filename.

This is a common occurrence. The Verify button works with S/MIME certificates only. It does not work with object-signing certificates.

To verify an object-signing certificate, use

signtool -l -k nickname

where nickname is the nickname of the certificate you want to verify.

failure authenticating to key database .: Security I/O error. 

This error typically means that you have not yet set a password for the certificate database. To set the password for the Communicator database, click the Security icon in the Communicator toolbar, click Passwords, and click Set Password to create a password.

Although certificates expire, valid signatures do not. Signature validation is based on the date of the signature rather than the time verification occurs. If a certificate chain was valid at signing, Communicator will continue to recognize that signature even after certificates in that chain expire. Note that this would not be true, however, if an object was signed using the -z option which omits the original timestamp and forces validation to rely on the current status of the certificate chain.

Last Updated: 06/19/98 13:23:55

Any sample code included above is provided for your use on an "AS IS" basis, under the Netscape License Agreement - Terms of Use