tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Qingqing Ouyang <>
Subject Re: cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net
Date Fri, 20 Sep 2002 22:16:58 GMT
>>1. Tomcat has enough information to determine the incoming
>>    request is intended for a Context that requires the
>>    client-cert authentication
> True.  However it is unnecessary to do it for the entire Context.  It is
> only necessary for the pages that require authentication.

Yes!  Couldn't agree more!  Thanx for being very precise.

>>2. Tomcat also has to have the handle on the specific
>>    transport mechanism to force this second handshake with
>>    the client.
> "Tomcat" does, but Catalina doesn't.  All Catalina cares about is getting a
> client-cert, it shouldn't care how it gets it.  What it should do is ask
> Coyote to get the cert for it, since it's the only one that knows if it is
> talking to a JSSE socket, a PureTLS socket, or even talking directly to
> Apache via JNI.  The notification hook mechanism is already in Coyote.  It
> would just be adding one more hook.

Okay.  It does sound like we are in total agreement. :-)  If the
Coyote can take care of this,  that'll be great.

So would you be the person to implement this? ;-)

The tomcat 4.0 implementation for the re-handshake assumed that
the handshake is synchrouns.  But I believe the TLS spec says that
this second handshake is asyn.  So to be able to get the certificates
on the socket after the handshake, you'd have to register a

One word of warning though, it seems that the re-handshake behavior
has changed between JSSE 1.3 extensions to JDK 1.4?  Basically, the
reading of the certificates does not happen unless a read() is
performed.  In other words, after the server initiates the second
handshake, the client certificates will not be read until the server
actually reads something (also true on the client side).

I have already contacted the JSSE team at Sun for verification of
this behavior change and possible workarounds?  I will keep you
updated on that one.


>>3. The certificate information also has to be populated with
>>    the Request object for further authorization calls...
>>Does that sound right?
>>To unsubscribe, e-mail:
> <>
>>For additional commands, e-mail:
> <>
> --
> To unsubscribe, e-mail:   <>
> For additional commands, e-mail: <>

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message