Firstly I would *Strongly* recommend filing a bug report at http://nagoya.apache.org/bugzilla, simply so that it doesn't get lost in the traffic on this list.
The basic problem is that the JSSE that ships with JDK1.4 doesn't allow simply sending back a re-handshake request. It won't actually send it down the wire until there is content to send as well. This is what is confusing Mozilla & Netscape (since Tomcat tries (it seems, unsuccessfully :(, to fake the browser out when running under JDK1.4). As I mentioned before, a short-term solution is to use PureTLS from http://www.claymoresystems.com/puretls_main.html. All you need to do is to install the jars in $CATALINA_HOME/server/lib, and Tomcat will use it by preference. "Tony Dahbura" <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > The problem does go away with jdk 1.3 using jsse software instead of jdk 1.4. > > How do we fix it for jdk 1.4? > > Tony > > > > > Tony Dahbura wrote: > > > Bill: > > Can you tell me how or point me to some docs on how to do the tcp traces > > you are requesting? > > > > I can certainly run some test cases and deposit them in the bug report. > > Yes I am using jdk 1.4! > > > > Thanks, > > Tony > > > > Bill Barker wrote: > > > > >"Tony Dahbura" <[EMAIL PROTECTED]> wrote in message > > >[EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > > > > > > > >>Team: > > >>I have noticed something very inconsistent within Tomcat 4.1.18. > > >> > > >>My application is using client certificates over ssl (these all occur > > >>after I unlock and present my certificate (which btw is the same on all > > >>three of these browsers). > > >> > > >>When I access my protected resource with IE version 6.0 all works fine. > > >> > > >>When I access my protected resource with Mozilla version 1.1 I receive > > >>an error page from tomcat that says: > > >>HTTP Status 400 - No client certificate chain in this request. > > >>Description:The request sent by the client was syntactically incorrect > > >>(No client certificate chain in this request). > > >>If I hit reload it works fine. > > >> > > >>When I access my protected resource with Netscape Communicator I receive > > >>a blank page. > > >>After hitting reload I am prompted for my certificate again and it works > > >>correctly. > > >> > > >>I believe this message is being generated by the following code in > > >>org.apache.catalina.authenticator.SSLAuthenticator.java: > > >> > > >>// Retrieve the certificate chain for this client > > >> HttpServletResponse hres = > > >> (HttpServletResponse) response.getResponse(); > > >> if (debug >= 1) > > >> log(" Looking up certificates"); > > >> X509Certificate certs[] = (X509Certificate[]) > > >> > > >>request.getRequest().getAttribute(Globals.CERTIFICATES_ATTR); > > >> if ((certs == null) || (certs.length < 1)) { > > >> certs = (X509Certificate[]) > > >> > > >>request.getRequest().getAttribute(Globals.SSL_CERTIFICATE_ATTR); > > >> } > > >> if ((certs == null) || (certs.length < 1)) { > > >> if (debug >= 1) > > >> log(" No certificates included with this request"); > > >> hres.sendError(HttpServletResponse.SC_BAD_REQUEST, > > >> sm.getString("authenticator.certificates")); > > >> return (false); > > >> } > > >> > > >>My question is why the inconsistent behavior between browsers? Secondly > > >>if I do not do cert authentication within my webapp but instead turn it > > >>on for the whole SSL context (using clientAuth) I do not get this > > >>message with any of the above mentioned browsers. > > >> > > >> > > > > > >The special (internal to Tomcat) 'SSL_CERTIFICATE_ATTR' attribute causes > > >Tomcat to re-negotiate the handshake with the additional requirement of a > > >client cert if there isn't already a cert present (and this is why > > >clientAuth works). > > > > > >In addition, for the JDK1.4 of JSSE, there are some tricks to get around > > >that version's refusal to re-negotiate until there is real traffic on the > > >Socket. This is probably what is confusing Mozilla & Netscape. You can > > >file a bug-report at http://nagoya.apache.org/bugzilla/, but it would be > > >more helpful (and very welcome :) if you could include the TCP traces as > > >well. > > > > > >I'm guessing that you are using JDK1.4. I'm also guessing that down-grading > > >to JDK1.3.1.x+JSSE 1.0.2 would suddenly cause everything to start working. > > >Another option would be to use PureTLS (http://www.rtfm.com/puretls/). I > > >haven't tried it with JDK1.4.x, but it works well with JDK1.3.1.x. > > > > > > > > > > > > > > >>Thanks, > > >>Tony > > >> > > >> > > >> > > >>-- > > >>Tony Dahbura > > >>Deployment Director > > >>Opsware Business Practice > > >>EDS Inc. > > >>13900 Lincoln Park Drive > > >>Suite 405/WH-OPS > > >>Herndon, VA 20171 > > >>voice: 703.742.1280 > > >>fax: 703.742.1163 > > >>[EMAIL PROTECTED] > > >> > > >> > > > > > > > > > > > > > > >--------------------------------------------------------------------- > > >To unsubscribe, e-mail: [EMAIL PROTECTED] > > >For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > -- > Tony Dahbura > Deployment Director > Opsware Business Practice > EDS Inc. > 13900 Lincoln Park Drive > Suite 405/WH-OPS > Herndon, VA 20171 > voice: 703.742.1280 > fax: 703.742.1163 > [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
