----- Original Message -----
From: "Qingqing Ouyang" <[EMAIL PROTECTED]>
To: "Tomcat Developers List" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, September 19, 2002 6:40 PM
Subject: Re: cvs commit:
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net
JSSESocketFactory.java
> Hi, Bill:
>
> I have a question regarding your comment on the CertificatesValve should
> not be used any more...
>
> My understanding of how the CertificatesValve is used is following:
>
> 1. The clientAuth attribute in server.xml only determines whether
> the Tomcat server by default will require client certificate
> to authenticate (the default is false).
>
> 2. When a web app (servlet/jsp) that requires client auth
> (<auth-method>CLIENT-CERT</auth-method>) is deployed in the Tomcat
> server, Tomcat will install a CertificatesValve for the context
> of this web app (regardless what Connector is used to process
> https)
>
> 3. When a client opens a HttpsURLConnection to the protected web
> resource, the CertificatesValve is invoked. And all it does is
> to recognized that client auth is needed -- so it invalidates the
> current socket session and forces a re-handshake with the client
> -- hence the client authentication happens.
>
> It seems to me that the JSSESocketFactory only takes care of the first
> handshake. If Tomcat does not support a re-handshake, then how
> can Tomcat dynamically discover that a client needs to send it's
> certificate?
>
> Can someone start the Tomcat server with clientAuth=false, but access
> a URI that is protected by CLIENT-CERT? If yes, then I think a
> re-handshake is a must.
But using CertificatesValve to accomplish this is the wrong way to do it.
Catalina has no good reason to know or care what transport the request was
received on. It's the connector's job to take care of that.
It looks like we may need another Action to handle this case (probably
invoked by the Realm). Comments?
>
> Please lemme know if I am missing something here?
>
> Thanx so much for your help!
> Q^2
>
> [EMAIL PROTECTED] wrote:
> > billbarker 2002/09/18 22:09:28
> >
> > Modified: util/java/org/apache/tomcat/util/net
JSSESocketFactory.java
> > Log:
> > Fix problem with JSSE not honoring "clientauth".
> >
> > Now there should be now reason for anyone to believe that
CertificatesValve should be used ever with the CoyoteConnector. :-)
> >
> > Revision Changes Path
> > 1.3 +16 -2
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/JSSESocketFac
tory.java
> >
> > Index: JSSESocketFactory.java
> > ===================================================================
> > RCS file:
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/JSS
ESocketFactory.java,v
> > retrieving revision 1.2
> > retrieving revision 1.3
> > diff -u -r1.2 -r1.3
> > --- JSSESocketFactory.java 18 Sep 2002 15:10:04 -0000 1.2
> > +++ JSSESocketFactory.java 19 Sep 2002 05:09:28 -0000 1.3
> > @@ -161,7 +161,18 @@
> >
> > //determine whether we want client authentication
> > // the presence of the attribute enables client auth
> > - clientAuth = null != (String)attributes.get("clientauth");
> > + String clientAuthStr=(String)attributes.get("clientauth");
> > + if(clientAuthStr != null){
> > + if(clientAuthStr.equals("true")){
> > + clientAuth=true;
> > + } else if(clientAuthStr.equals("false")) {
> > + clientAuth=false;
> > + } else {
> > + throw new IOException("Invalid value '" +
> > + clientAuthStr +
> > + "' for 'clientauth' parameter:");
> > + }
> > + }
> >
> > String keyPass=(String)attributes.get("keypass");
> > if( keyPass==null) keyPass=defaultKeyPass;
> > @@ -224,11 +235,14 @@
> > public Socket acceptSocket(ServerSocket socket)
> > throws IOException
> > {
> > + SSLSocket asock = null;
> > try {
> > - return socket.accept();
> > + asock = (SSLSocket)socket.accept();
> > + asock.setNeedClientAuth(clientAuth);
> > } catch (SSLException e){
> > throw new SocketException("SSL handshake error" + e.toString());
> > }
> > + return asock;
> > }
> >
> > /** Set server socket properties ( accepted cipher suites, etc)
> >
> >
> >
> >
> > --
> > 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]>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
