On Wed, 18 Sep 2002, Bill Barker wrote:
> Date: Wed, 18 Sep 2002 12:06:50 -0700
> From: Bill Barker <[EMAIL PROTECTED]>
> Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> To: Tomcat Developers List <[EMAIL PROTECTED]>
> Subject: Re: cvs commit:
> jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11
> Http11Processor.java
>
>
> ----- Original Message -----
> From: <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, September 18, 2002 9:44 AM
> Subject: cvs commit:
> jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11
> Http11Processor.java
>
>
> > bobh 2002/09/18 09:44:35
> >
> > Modified: . gump.xml
> > coyote/src/java/org/apache/coyote Request.java
> > http11/src/java/org/apache/coyote/http11
> > Http11Processor.java
> > Log:
> > - This associates the socket with the Request. This is so the
> > CertificatesValve.verify() can tell where (which socket) the Request
> > is comeing from. Without this association, CertificatesValve.verify()
> > returns with no SSL Handshake.
> > - this change is in part based on feed back from; Vivek N. Yingxian
> > Wang (JSSE), Craig M., Qingqing Ouyang
> >
>
> I'm -1 on this, since having a socket in the Request makes no sense for Jk2.
> CertificatesValve is only for use with the deprecated HttpConnector. With
> Coyote, the SSL handling has moved to the connector (where it belonged in
> the first place).
>
The current Tomcat standalone implementation does not appear to meet the
spec requirements for exposing a certificate chain, or for implementing
CLIENT-CERT authentication. For the latter, the container needs to
challenge the client to send a certificate if they didn't do so already.
How do you propose to meet those requirements for Tomcat stand-alone
without access to the underlying SSL socket? (For the connectors, you'll
obviously need to provide an alternative solution to meet the spec
requirements).
Craig
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
