JDK-4681247 : REGRESSION: Applet not loaded with JRE1.4 when SSL Client Authentication reqd
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: 1.4.0
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_nt,windows_2000
  • CPU: x86
  • Submitted: 2002-05-08
  • Updated: 2002-11-19
  • Resolved: 2002-11-19
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 Other
1.4.1_02 02Fixed 1.4.2Fixed
Related Reports
Duplicate :  
JDK-4607433 - Unable to perform HTTPS client authentication using plugin
Duplicate :  
JDK-4614560 - REGRESSION: Applet not loaded with JRE1.4-b3, Client Authentication required
Duplicate :  
JDK-4683318 - Plug-in unable to load classes from a web server requiring a client certificate
Relates :  
JDK-4885165 - Client authentication using Java Card no longer works in 1.4
Description
Name: gm110360			Date: 05/07/2002


FULL PRODUCT VERSION :
java version "1.4.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-b92)
Java HotSpot(TM) Client VM (build 1.4.0-b92, mixed mode)


FULL OPERATING SYSTEM VERSION :
Microsoft Windows 2000 [Version 5.00.2195]

A DESCRIPTION OF THE PROBLEM :
Symptom:

Applets cannot be loaded with JRE1.4.0 when SSL Client
Authentication is required by webserver.
And finally ClassNotFoundException occurs.
The same system has been working fine with Java Plug-in
1.3.1_03.

This problem occurs only when I am writing the following
line in apache's httpd.conf to specify Client
Authentication.
  SSLVerifyClient require

and doesn't reproduce this when No Client Authentication
required and the applet is loaded normally and works.
  


Environment:

Server:
LASER5 Linux 7.1
Apache/1.3.24
mod_ssl/2.8.8
OpenSSL/0.9.6c

Client:
Windows2000
Internet Explorer 6.0
Netscape 6.2
JRE_1.4.0




REGRESSION.  Last worked in version 1.3

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1.Prepare SSL enabled webserver which provides an applet-
showing html.
2.Configure webserver to require client certificate for
authentication.
3.Show the html page with HTTPS.


ERROR MESSAGES/STACK TRACES THAT OCCUR :
java.net.SocketException: Software caused connection abort: JVM_recv in socket
input stream read
	at java.net.SocketInputStream.socketRead0(Native Method)
	at java.net.SocketInputStream.read(SocketInputStream.java:119)
	at com.sun.net.ssl.internal.ssl.InputRecord.a(DashoA6275)
	at com.sun.net.ssl.internal.ssl.InputRecord.read(DashoA6275)
	at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
	at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
	at com.sun.net.ssl.internal.ssl.HandshakeOutStream.flush(DashoA6275)
	at com.sun.net.ssl.internal.ssl.Handshaker.sendChangeCipherSpec
(DashoA6275)
	at com.sun.net.ssl.internal.ssl.ClientHandshaker.g(DashoA6275)
	at com.sun.net.ssl.internal.ssl.ClientHandshaker.a(DashoA6275)
	at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage
(DashoA6275)
	at com.sun.net.ssl.internal.ssl.Handshaker.process_record(DashoA6275)
	at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
	at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
	at com.sun.net.ssl.internal.ssl.AppInputStream.read(DashoA6275)
	at java.io.BufferedInputStream.fill(BufferedInputStream.java:186)
	at java.io.BufferedInputStream.read1(BufferedInputStream.java:225)
	at java.io.BufferedInputStream.read(BufferedInputStream.java:280)
	at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:722)
	at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:685)
	at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:693)
	at sun.net.www.protocol.http.HttpURLConnection.getInputStream
(HttpURLConnection.java:558)
	at sun.net.www.protocol.http.HttpURLConnection.getHeaderField
(HttpURLConnection.java:1092)
	at sun.net.www.protocol.https.HttpsURLConnectionImpl.getHeaderField
(DashoA6275)
	at sun.net.www.protocol.https.PluginHttpsURLConnection.checkCookieHeader
(PluginHttpsURLConnection.java:341)
	at sun.net.www.protocol.https.PluginHttpsURLConnection.getInputStream
(PluginHttpsURLConnection.java:299)
	at sun.plugin.net.protocol.http.HttpUtils.followRedirects
(HttpUtils.java:41)
	at sun.plugin.cache.CachedJarLoader.download(CachedJarLoader.java:341)
	at sun.plugin.cache.CachedJarLoader.load(CachedJarLoader.java:112)
	at sun.plugin.cache.JarCache.get(JarCache.java:170)
	at sun.plugin.net.protocol.jar.CachedJarURLConnection.connect
(CachedJarURLConnection.java:73)
	at sun.plugin.net.protocol.jar.CachedJarURLConnection.getJarFile
(CachedJarURLConnection.java:58)
	at sun.misc.URLClassPath$JarLoader.getJarFile(URLClassPath.java:501)
	at sun.misc.URLClassPath$JarLoader.<init>(URLClassPath.java:462)
	at sun.misc.URLClassPath$2.run(URLClassPath.java:258)
	at java.security.AccessController.doPrivileged(Native Method)
	at sun.misc.URLClassPath.getLoader(URLClassPath.java:247)
	at sun.misc.URLClassPath.getLoader(URLClassPath.java:224)
	at sun.misc.URLClassPath.getResource(URLClassPath.java:137)
	at java.net.URLClassLoader$1.run(URLClassLoader.java:193)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.URLClassLoader.findClass(URLClassLoader.java:189)
	at sun.applet.AppletClassLoader.findClass(AppletClassLoader.java:134)
	at sun.plugin.security.PluginClassLoader.findClass
(PluginClassLoader.java:191)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:309)
	at sun.applet.AppletClassLoader.loadClass(AppletClassLoader.java:114)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:265)
	at sun.applet.AppletClassLoader.loadCode(AppletClassLoader.java:470)
	at sun.applet.AppletPanel.createApplet(AppletPanel.java:551)
	at sun.plugin.AppletViewer.createApplet(AppletViewer.java:1610)
	at sun.applet.AppletPanel.runLoader(AppletPanel.java:480)
	at sun.applet.AppletPanel.run(AppletPanel.java:293)
	at java.lang.Thread.run(Thread.java:539)
java.lang.ClassNotFoundException: SwingSet2Applet
	at sun.applet.AppletClassLoader.findClass(AppletClassLoader.java:153)
	at sun.plugin.security.PluginClassLoader.findClass
(PluginClassLoader.java:191)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:309)
	at sun.applet.AppletClassLoader.loadClass(AppletClassLoader.java:114)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:265)
	at sun.applet.AppletClassLoader.loadCode(AppletClassLoader.java:475)
	at sun.applet.AppletPanel.createApplet(AppletPanel.java:551)
	at sun.plugin.AppletViewer.createApplet(AppletViewer.java:1610)
	at sun.applet.AppletPanel.runLoader(AppletPanel.java:480)
	at sun.applet.AppletPanel.run(AppletPanel.java:293)
	at java.lang.Thread.run(Thread.java:539)
Caused by: java.net.SocketException: Software caused connection abort: JVM_recv
in socket input stream read
	at java.net.SocketInputStream.socketRead0(Native Method)
	at java.net.SocketInputStream.read(SocketInputStream.java:119)
	at com.sun.net.ssl.internal.ssl.InputRecord.a(DashoA6275)
	at com.sun.net.ssl.internal.ssl.InputRecord.read(DashoA6275)
	at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
	at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
	at com.sun.net.ssl.internal.ssl.HandshakeOutStream.flush(DashoA6275)
	at com.sun.net.ssl.internal.ssl.Handshaker.sendChangeCipherSpec
(DashoA6275)
	at com.sun.net.ssl.internal.ssl.ClientHandshaker.g(DashoA6275)
	at com.sun.net.ssl.internal.ssl.ClientHandshaker.a(DashoA6275)
	at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage
(DashoA6275)
	at com.sun.net.ssl.internal.ssl.Handshaker.process_record(DashoA6275)
	at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
	at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
	at com.sun.net.ssl.internal.ssl.AppInputStream.read(DashoA6275)
	at java.io.BufferedInputStream.fill(BufferedInputStream.java:186)
	at java.io.BufferedInputStream.read1(BufferedInputStream.java:225)
	at java.io.BufferedInputStream.read(BufferedInputStream.java:280)
	at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:722)
	at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:685)
	at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:693)
	at sun.net.www.protocol.http.HttpURLConnection.getInputStream
(HttpURLConnection.java:558)
	at sun.net.www.protocol.http.HttpURLConnection.getHeaderField
(HttpURLConnection.java:1120)
	at sun.net.www.protocol.http.HttpURLConnection.getResponseCode
(HttpURLConnection.java:1134)
	at sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode
(DashoA6275)
	at sun.applet.AppletClassLoader.getBytes(AppletClassLoader.java:224)
	at sun.applet.AppletClassLoader.access$100(AppletClassLoader.java:42)
	at sun.applet.AppletClassLoader$1.run(AppletClassLoader.java:143)
	at java.security.AccessController.doPrivileged(Native Method)
	at sun.applet.AppletClassLoader.findClass(AppletClassLoader.java:140)
	... 10 more


This bug can be reproduced always.

Release Regression From : 1.3.1_03
The above release value was the last known release where this 
bug was known to work. Since then there has been a regression.

(Review ID: 145569) 
======================================================================
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.4.1_02 mantis FIXED IN: 1.4.1_02 mantis INTEGRATED IN: 1.4.1_02 mantis mantis-b08
14-06-2004
EVALUATION Commit to mantis ###@###.### 2002-07-30 ------------------------------------------------------------------ In the SSLHandshake process, after the 'serverhello' that follows with the Certificate Request, client is supposed to send its own certificate to server. But in the SSL trace I see that client is not able to find the certificate that matches the server's certificate request criteria. So it sends a no_certificate alert to server, after which the server closes the connection. I set the client certificate store by setting the system property '-Djavax.net.ssl.keyStore=<path to client keystore>. This keystore meets the criteria requested by the server. In the JSSE logs, I see that this keystore is loaded by JSSE. But even then after 'serverhello', client does not send its certificate as it is not able to find it. I ran a simple testcase which creates the SSLContext and SSLSocket and invokes the Handshake. While running this testcase, I set the property -Djavax.net.ssl.keyStore=<path to client keystore> on command line. This handshake passes. This makes me think that plugin somehow overides the keystore path. ###@###.### 2002-09-11 ------------------------------------------------- ###@###.### 2003-03-31 The current fix for this bug in Mantis and 1.4.1_02 is using JSSE API, Here are the step: In Java control panel, Advanced tab -> Java Runtime Parameters, specify: -Djavax.net.ssl.keyStore=<name and path to client keystore file> -Djavax.net.ssl.keyStorePassword=<password to access this client keystore file> If it is a PKCS12 format keystore, specify: -Djavax.net.ssl.keyStoreType=PKCS12 In our future JRE release 1.5, we will create our own client authentication keystore file for JPI and use that for client authentication, for detail info, please see RFE 4797512. Dennis
11-06-2004
PUBLIC COMMENTS ###@###.### 2003-03-31 The current fix for this bug in 1.4.2-beta and 1.4.1_02 is using JSSE API, Here are the step: In Java control panel, Advanced tab -> Java Runtime Parameters, specify: -Djavax.net.ssl.keyStore=<name and path to client keystore file> -Djavax.net.ssl.keyStorePassword = <password to access this client keystore file> Currently, it only support "JKS" format, another bug 4840325 ask support for 'PKCS12' format. We will implement it in 1.4.2-rc and later update release by specify: -Djavax.net.ssl.keyStoreType = PKCS12 In our future JRE release 1.5, we will create our own client authentication keystore file for JPI and use that for client authentication, for detail info, please see RFE 4797512. Dennis
10-06-2004