Applet loading over ssl problem. Apache and tomcat Urgent Help

Hi ,

We are using Apache 2.0 version as a webserver and tomcat 4.1.30 as the servlet container. The application runs under ssl. We have created a trust chain for the webserver with the CA. We have our own CA. we are using j2sdk1.4.2_05. JVM used is SUN JVM.

The issue is the following.

1. We are using client certificates to authenticate the client and establish the ssl connection. when connecting to a jsp page in the web application the IE certificate pops up and the client is authenticated. The request is then forwarded to the tomcat container and we can use the jsp page application.

So the client cert works for servlets and jsp pages

2. I have a jsp page where we have an applet. The applet is a signed applet. I have used a jks keystore to sign this applet. The keystore contains the complete certificate chain trustore and a user keystore.

The applet does not load and throws a ssl handshake error. The stack trace from the IE sun java console is attached at the end of the email. I did some investigation using the java.net.debug in the Java plug in and was able to isolate the problem. the problem says that there was no_certificate found.

if I understand the issue correctly to load the applet in IE the javaplugin launches the applet loader which eventially calls the sslcontext. And it makes the ssl connection and fails at the handshake. I think the webserver is not getting the certificate from this ssl request.

I tried the following . In the java plug-in "start up parameters" I set the system

properties

-Djavax.net.ssl.keyStore=example.keystore -Djavax.net.ssl.keyStorepassword=password.

As soon as I set these properties the applet loading gets the right certificate and trustore and the applet loads correctly.

This leads me to believe the X509 certificate is not sent when the applet loader tries to connect.

One possible soultion might be

Replacing the default applet loader with our custom loader which selects the right cert for making the sslconnection. If this is possible are there any examples around.

Are there any other suggestions

Stack Trace

javax.net.ssl.SSLException: Received fatal alert: unexpected_message

^ exception

at com.sun.net.ssl.internal.ssl.BaseSSLSocketImpl.a(Unknown Source)

at com.sun.net.ssl.internal.ssl.BaseSSLSocketImpl.b(Unknown Source)

at com.sun.net.ssl.internal.ssl.SSLSocketImpl.b(Unknown Source)

at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(Unknown Source)

at com.sun.net.ssl.internal.ssl.SSLSocketImpl.j(Unknown Source)

at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(Unknown Source)

^ handshake means that trying to connect to tomcats webapp context I guess

at sun.net.http://www.protocol.https.HttpsClient.afterConnect(Unknown Source)

at sun.net.http://www.protocol.https.Abstr actDelegateHttpsURLConnection.setNewClient(Unknown Source)

at sun.net.http://www.protocol.https.PluginD elegateHttpsURLConnection.superConnect(Unknown Source)

at sun.net.http://www.protocol.https.PluginDelegateHttpsURLConnection.connect(Unknown Source)

at sun.net.http://www.protocol.https.Plugi nDelegateHttpsURLConnection.getInputStream(Unknown Source)

at sun.net.http://www.protocol.https.HttpsURLConnectionImpl.getInputStream(Unknown Source)

^ HttpsURLConnection stream readfor jar contents

at sun.plugin.net.protocol.http.HttpUtils.followRedirects(Unknown Source)

^ may be failed or might be disabled

at sun.plugin.cache.CachedJarLoader.isUpToDate(Unknown Source)

at sun.plugin.cache.CachedJarLoader.loadFromCache(Unknown Source)

^ load from cache

at sun.plugin.cache.CachedJarLoader.load(Unknown Source)

at sun.plugin.cache.JarCache.get(Unknown Source)

at sun.plugin.net.protocol.jar.CachedJarURLConnection.connect(Unknown Source)

at sun.plugin.net.protocol.jar.CachedJarURLConnection.getJarFile(Unknown Source)

^ getJarFile from codebase location

at sun.misc.URLClassPath$JarLoader.getJarFile(Unknown Source)

at sun.misc.URLClassPath$JarLoader.<init>(Unknown Source)

at sun.misc.URLClassPath$3.run(Unknown Source)

at java.security.AccessController.doPrivileged(Native Method)

at sun.misc.URLClassPath.getLoader(Unknown Source)

at sun.misc.URLClassPath.getLoader(Unknown Source)

at sun.misc.URLClassPath.getResource(Unknown Source)

at java.net.URLClassLoader$1.run(Unknown Source)

at java.security.AccessController.doPrivileged(Native Method)

at java.net.URLClassLoader.findClass(Unknown Source)

^ URLClassLoader as there is codebase pointing to URL

at sun.applet.AppletClassLoader.findClass(Unknown Source)

^findClass to load

at java.lang.ClassLoader.loadClass(Unknown Source)

at sun.applet.AppletClassLoader.loadClass(Unknown Source)

^ passed to AppletClassLoader

at java.lang.ClassLoader.loadClass(Unknown Source)

^ request to load Applet

at sun.applet.AppletClassLoader.loadCode(Unknown Source)

at sun.applet.AppletPanel.createApplet(Unknown Source)

at sun.plugin.AppletViewer.createApplet(Unknown Source)

at sun.applet.AppletPanel.runLoader(Unknown Source)

at sun.applet.AppletPanel.run(Unknown Source)

at java.lang.Thread.run(Unknown Source)

[5921 byte] By [xml_abha] at [2007-10-1 1:24:50]
# 1
Hi,I was just wondering, if you were able to get this problem resolved. I have the exact problem and thought may be I could benefit from your findings. If you could kindly post anything you jhave since found out I'd really appreciate itThanksSantosh
shubhatosha at 2007-7-8 1:44:35 > top of Java-index,Desktop,Core GUI APIs...
# 2

Well, it has at least nothing to do with Tomcat (we have the same issues with BEA and Apache)

The thing is that the applet (or more specifically the jvm) does not have access to the browser keystore (unfortunately) I think this is one of the major issues Sun has to solve for applets to become a viable option in some B2B environments. What we did, is put the applet on a https url without certifcate based authentication and use the codebase param to tell the jvm where to load the applet.

Ronald

rtvkuijka at 2007-7-8 1:44:35 > top of Java-index,Desktop,Core GUI APIs...