Java Applets

Like any browser-based applet, permission to access (read/write) local resources is handled differently across browser platforms (and associated JVMs). Netscape DB KeyStore requires read access to local resources (namely file i/o) to operate correctly. Mechanisms required to obtain these permissions are the responsibility of the applet and not of Netscape DB KeyStore.

Entry Creation Date

Calls to the KeyStoreSPI for getCreationDate() return the Java Data/Time for when the Netscape Browser database was opened and information was read from disk by Netscape DB KeyStore. Netscape Browser Database files do not store information as to when the entry was placed in either key3.db or cert7.db. It is for this reason that creation date information for Netscape DB entries should be ignored at this time.

Entrust, Versions Prior to 4.1

NDBS 2.0 was tested having Entrust as one of the crypto providers installed in the JRE_HOME/lib/ext directory. Because the Java Runtime checks the providers in alphabetical order when initializing its crypto classes, it always encountered the entrust.jar file first and threw an IncompatibleClassChangeError or ClassNotFound exception. If this file was moved out of that directory, the tests were successful. Further research on the Internet showed a posting on a bulletin board stating that there was a bug in Entrust that required it to call com.entrust.util.Util.initCiphers() before any of their algorithms could be used. This was confirmed in the documentation for version 4.1 of Entrust where it had been fixed. After requesting and installing the new version of Entrust, it does not present a problem.

Specific Certificate Problems

NDBS 2.0 will fail if it encounters a certificate in which the X.509v3 alternative name extensions SubjectAlternativeNameExtension or IssuerAlternativeNameExtension have an empty GeneralNames Sequence. The X.509 v3 specification clearly states that this is not allowed. There are several reports on OpenSSL newsgroups stating that there are CAs generating certificates with this problem.

A call to the KeyStore.getCertificate() method will fail with these certificates because the Java method CertificateFactory.generateCertificate() used by getCertificate() will throw a NullPointerException and return a null certificate, which is not expected. This will also cause problems in keytool using the -list option with no alias to list all certificates in the keystore or when specifying an alias to a certificate that is invalid.

This certificate error has been fixed in the Beta release of the JavaTM 2 Platform, Standard Edition version 1.4, but that there is still an unhandled NullPointerException due to an unknown key specification when executing CertificateFactory.generateCertificate() and that the web site will be updated as soon as further information is available.

Duplicate Aliases

NDBS 2.0 will not allow duplicate aliases. If it encounters one when loading the keystore, it will write an entry to a log file named NDBS.log, located in the same directory as the keystore.

Adding E-mail Certificates

NDBS 2.0 can only add CA and personal certificates to the keystore. It cannot add e-mail certificates because the MIME options required by the Netscape database to form an S/MIME profile record cannot be determined from the certificate information. If an e-mail address is used as an alias, NDBS 2.0 will create a Nickname record and set the e-mail address as nickname.

Adding CA Certificates

NDBS 2.0 will mark a certificate as a CA certificate only if it finds the BasicConstraints OID extension.

Setting Flags for Certificates

NDBS 2.0 will set the SSL, S/MIME e-mail, and object signing flags to 0x0018 (trusted CA certificate) if the certificate belongs to a CA. If it is not a CA certificate, the set of flags will be set to 0x0040 (user certificate).

Rewriting Certificates

If a certificate with a given alias already exists in the keystore, it will only be overwritten if their public keys match.

Only One Implementation of setKeyEntry()

NDBS only implements setKeyEntry() for keys that are stored in a java.security.PrivateKey class. It will not work with protected keys store in byte arrays because Netscape uses the same password for protecting both its keys and the actual keystore, and the key to be written to the keystore could have been protected with a different password.

Trusted Entries

NDBS 2.0 does not validate if a certificate entry is trusted before adding it to a keystore. The programmer will have to determine if a certificate is trusted before calling the setCertificateEntry() and setKeyEntry() methods.

Adding Private Key Entries

NDBS 2.0 will add a private key entry with more than one certificate in its certificate chain (not self-signed) only if all the certificates in the chain exist in the keystore.

Bug in Berkeley DB Code

There is a bug in the Berkeley DB code that corrupts the database if over 30 records are written at a time. This bug should not present itself in NDBS because a normal scenario does not write over 30 records at a time. We will continue searching for the cause of the bug.

Using JDK 1.4

JCE was previously an optional package (extension) to the JavaTM 2 SDK, Standard Edition (J2SDK), versions 1.2.x and 1.3.x. JCE has now been integrated into the J2SDK, v 1.4. The problem is that due to import control restrictions, the jurisdiction policy files shipped with the J2SDK, v 1.4 allow "strong" but limited cryptography to be used. This requires you to download an "unlimited strength" version of these files if you are going to use NDBS with J2SDK 1.4. This version is available for those living in eligible countries (which is most countries) at

http://java.sun.com/products/jce/index-14.html

The jurisdiction policy files have been relocated to

JAVA_HOME\lib\security [Win32]
JAVA_HOME/lib/security [Solaris]

where JAVA_HOME refers to the directory where the runtime software is installed, which is the top-level directory of the JavaTM 2 Runtime Environment (JRE) or the jre directory in the JavaTM 2 SDK (J2SDK) software. They have been moved to this standard location so that it is easy to replace the strong cryptography versions that come with the J2SDK, v 1.4 with the unlimited ones. You are better off if you copy them to both places.