----- Original Message -----
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Sent: Wednesday, September 18, 2002 12:34 PM
Subject: Re: cvs commit:
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11
Http11Processor.java


>
>
> 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).

The correct place to fix it is
o.a.t.u.net.JSSESupport.getPeerCertificateChain (called from
o.a.c.http11.Http11Processor.action).  The code there was so heavily cribbed
from CertificatesValve, that I should probably add you to the @author. :-)

I'm strongly against reverting TC 4/5 back to only supporting JSSE (which
would be the effect of requiring CertificatesValve).

>
> Craig
>
>
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
>


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to