JDK-4957907 : Support Mozilla browser keystore and smart card in Java Plug-in and Web Start
  • Type: Enhancement
  • Component: deploy
  • Sub-Component: deployment_toolkit
  • Affected Version: 1.4.2,5.0
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris_9,windows_xp
  • CPU: unknown,x86
  • Submitted: 2003-11-21
  • Updated: 2004-03-23
  • Resolved: 2004-03-23
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
5.0 b44Fixed
Related Reports
Duplicate :  
JDK-4901036 - Java Plug-in Cannot make use of token keystores
Description
1. History

	Prior to Merlin, Java Plug-in used browser APIs in Internet Explorer and Netscape to support HTTPS. Browser keystores were used transparently by the browser APIs, and the certificates and keys in browser keystores were used in signing verification, SSL server/client authentication. Also, Internet Explorer and Netscape supports smart card for SSL client authentication through their keystore providers as well. 

	Unfortunately, the browser APIs exposed for HTTPS were problematic especially in Netscape, and customers found many general cases that HTTPS didn't work properly in plugin because of the underlying problem in the browser APIs. As a result, in Merlin, Java Plug-in switched to JSSE (Java Secure Socket Extension) to support HTTPS, and it solved most of the outstanding HTTPS plugin bugs submitted by customers.

	However, by default, JSSE uses its own keystore that is not integrated with the browsers, and there is no support for enterprise keystore deployment. While customers could deploy their certificates/keys using keytool on each machine, this is unacceptable to them on a large scale deployment basis. They would like Java Plug-in to recognize certificates and keys in browser keystore, so they could use their existing deployment mechanism for the browser to deploy certificates/keys for plugin. Also, JSSE doesn't have built-in smart card support, so customers could not use their smart card in SSL client authentication in Merlin. 

2. Solution

	The solution is to expose the browser keystores to JSSE when running in plugin/webstart in Tiger. Microsoft exposed browser keystore access through Crypto APIs, and Netscape exposed the access through PKCS#11. The browser keystore would be used in three areas:

a. Signing verification using root CA and trusted certificates from browser's root CA store and trusted store.
b. SSL server authentication using root CA certificates from browser's root CA store.
c. SSL client authentication using personal certificates and keys from browser's personal store.

Plugin/webstart would leverage certificates and keys from the browser in additional to the default Java keystore. Browser keystore providers also has built-in smart card support, so the smart card support would be incorporated automatically into plugin as the result of the browser keystore support. In addition, a new advanced option would be added to the Java Control Panel, and customers could disable the browser keystore support on their machines if necessary.

        Based on customer feedbacks, this RFE should support the following:

a. Browser keystore and smart card support through Internet Explorer on Windows
b. Browser keystore and smart card support through Mozilla on Windows/Solaris/Linux

	In Tiger, the underlying deployment infrastructure have been merged between Java Plug-in and Java Web Start; adding browser keystore and smart card support in plugin would automatically enable the support in webstart as well. 

        This RFE is similar to 4480333 but is specific for Mozilla browsers.

###@###.### 2003-11-20
###@###.### 2003-11-20
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: tiger-beta2 FIXED IN: tiger-beta2 INTEGRATED IN: tiger-b44 tiger-beta2
08-07-2004
EVALUATION Commited to fix in Tiger beta 2. ###@###.### 2003-11-20 Basically, the browser keystore will be used for three purposes: 1. Signing verification using root CA certs 2. HTTP server authentication using root CA certs 3. HTTP client authentication using user keys/certs With browser keystore support, enterprise administrator will be able to distribute company-wide CA cert and user specific client cert for both the browser and J2RE using browser deployment tools. Mozilla has build-in PKCS#11 support, and we have been looking into the PKCS#11 support provided by our security in Tiger. However, we ran into two major blockers in our investigation in the past few weeks: 1. The root CA certificates in Mozilla are stored in nssckbi.dll. Although the library is exposed as PKCS#11 module, it is not fully compliance to the interface. Thus, when this module is used in Java, it would crash the VM, thus avoiding us to use the PKCS#11 Java wrapper to extract root CA certificates. Andreas from security team has confirmed there is currently no workaround. 2. The user keys/certificates are stored in one or more PKCS#11 modules in Mozilla. The PKCS#11 Java wrapper could communicate to individual PKCS#11 module if the Mozilla config information for the module is known, e.g. the location of the PKCS#11 module and its slot number. Unfortunately, these config info are stored in secmod.db in Mozilla's user profile, and there is no simple public Mozilla APIs to extract these information programmatically. In order to extract the information we need, it would require us to build one of our libraries using Mozilla source code (not just .h files, but actually code in many .c and .cpp files); this is a big problem because the source code use facilities like NSPR and NSS heavily, and the resulting library would have strong dependency on many Mozilla libraries. Also, using Mozilla source code in J2RE would require many build changes and be subjected to legal/export approval. The current Mozilla source code required for building plugin only contain a very small set of Mozilla headers, and there will be lots of internal process (e.g. Solaris ARC, RE, ...) to go through if we want to expand it. As a result, we cannot use the Java PKCS#11 support in Tiger to support Mozilla browser keystore in plugin/webstart. Mozilla browser keystore support is still desired by many of our customers, so we just begin the process this week to investigate other alternatives. One possibility is to use JSS (Network Security Service for Java): http://www.mozilla.org/projects/security/pki/jss/ JSS is provided by Mozilla as a Java wrapper around its Network Security Service. It provides access to root CA store as well as user keys/certificates from a high level without requiring developers to go under the PKCS#11 layer. The JSS native libraries perform unctfions very similar to what we would have done using Mozilla source code initially. However, because JSS is actually doing the work for us, all the Mozilla library dependency will be well isolated from J2SE. The only JSS dependency in plugin/webstart would be the JSS APIs at Java level. JSS is available as source download as well as binary download. Since people interested in Mozilla browser keystore support are mainly in the enterprise, we could require enterprise to deploy JSS along with Mozilla if they want to leverage browser keystore support in plugin/webstart, thus we could avoid the JSS distribution issue all together. ###@###.### 2004-02-10
10-02-2004