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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
