You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Jan Luehe <Ja...@Sun.COM> on 2003/06/06 01:29:30 UTC
Re:
cvscommit:jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11Http11Processor.javaHttp11Protocol.java
Bill,
> SSLAuthenticator makes a request for a special Request attribute
> ("org.apache.coyote.request.X509Certificate"), which fires off an Action
> hook (ACTION_REQ_SSL_CERTIFICATE) to renegotiate the handshake if necessary.
>
> I changed TC 5 a little while back to do a lazy-evaluation of the SSL
> attributes. If you are seeing problems, that might be where.
Well, the reason I was still using the (supposedly deprecated)
CertificatesValve was because it was still being added to the pipeline
in ContextConfig. I'm going to change ContextConfig as follows:
Index: ContextConfig.java
===================================================================
RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/ContextConfig.java,v
retrieving revision 1.25
diff -u -r1.25 ContextConfig.java
--- ContextConfig.java 14 May 2003 17:42:55 -0000 1.25
+++ ContextConfig.java 5 Jun 2003 23:08:13 -0000
@@ -497,7 +497,7 @@
Valve certificates = null;
try {
Class clazz =
- Class.forName("org.apache.catalina.valves.CertificatesValve");
+ Class.forName("org.apache.catalina.authenticator.SSLAuthenticator");
certificates = (Valve) clazz.newInstance();
} catch (Throwable t) {
return; // Probably JSSE classes not present
Even with this fix in place, the SSLAuthenticator's authenticate() method
was still not being invoked, because org.apache.catalina.authenticator.AuthenticatorBase
currently does not consider the CLIENT-CERT authentication constraint at
all.
After fixing this, the SSL handshake does get renegotiated in the way you
described, but for some reason the connection then times out. I'm still investigating.
Thanks for putting me on the right track, Bill!
Jan
P.S.: I'm also +1 for removing the CertificatesValve, since it is
confusing to have several valves essentially doing the same thing.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re:
cvscommit:jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11Http11Processor.javaHttp11Protocol.java
Posted by Jan Luehe <Ja...@Sun.COM>.
Remy,
> > P.S.: I'm also +1 for removing the CertificatesValve, since it is
> > confusing to have several valves essentially doing the same thing.
>
> There's no need to hardcode the authenticator, you only need to add it
> in startup.Authenticators.properties, and it will be added in the
> pipeline as needed. It's already there, BTW, so I don't quite see what's
> going on (but it should be fixed there, no harcoding required).
yes, I understand. The confusing part was that in ContextConfig, we
were adding both the CertificatesValve (in certificatesConfig) and the
Authenticator configured in web-app/login-config/auth-method, where
CertificatesValve and SSLAuthenticator were essentially doing the
same, except that CertificatesValve was operating on the (SSL)Socket
and was always failing on a CoyoteRequest (whose getSocket() always returns
null).
Bill has cleared up this confusion by removing the certificatesConfig() method.
Thanks,
Jan
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: cvscommit:jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11Http11Processor.javaHttp11Protocol.java
Posted by Remy Maucherat <re...@apache.org>.
Jan Luehe wrote:
> Bill,
>
>
>>SSLAuthenticator makes a request for a special Request attribute
>>("org.apache.coyote.request.X509Certificate"), which fires off an Action
>>hook (ACTION_REQ_SSL_CERTIFICATE) to renegotiate the handshake if necessary.
>>
>>I changed TC 5 a little while back to do a lazy-evaluation of the SSL
>>attributes. If you are seeing problems, that might be where.
>
>
> Well, the reason I was still using the (supposedly deprecated)
> CertificatesValve was because it was still being added to the pipeline
> in ContextConfig. I'm going to change ContextConfig as follows:
>
> Index: ContextConfig.java
> ===================================================================
> RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/ContextConfig.java,v
> retrieving revision 1.25
> diff -u -r1.25 ContextConfig.java
> --- ContextConfig.java 14 May 2003 17:42:55 -0000 1.25
> +++ ContextConfig.java 5 Jun 2003 23:08:13 -0000
> @@ -497,7 +497,7 @@
> Valve certificates = null;
> try {
> Class clazz =
> - Class.forName("org.apache.catalina.valves.CertificatesValve");
> + Class.forName("org.apache.catalina.authenticator.SSLAuthenticator");
> certificates = (Valve) clazz.newInstance();
> } catch (Throwable t) {
> return; // Probably JSSE classes not present
>
> Even with this fix in place, the SSLAuthenticator's authenticate() method
> was still not being invoked, because org.apache.catalina.authenticator.AuthenticatorBase
> currently does not consider the CLIENT-CERT authentication constraint at
> all.
>
> After fixing this, the SSL handshake does get renegotiated in the way you
> described, but for some reason the connection then times out. I'm still investigating.
>
> Thanks for putting me on the right track, Bill!
>
> Jan
>
> P.S.: I'm also +1 for removing the CertificatesValve, since it is
> confusing to have several valves essentially doing the same thing.
There's no need to hardcode the authenticator, you only need to add it
in startup.Authenticators.properties, and it will be added in the
pipeline as needed. It's already there, BTW, so I don't quite see what's
going on (but it should be fixed there, no harcoding required).
Remy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org