tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 34643] - document how to use certificate-based "clientAuth" on a per user or per session basis also with self-signed/expired client certs
Date Wed, 11 May 2005 13:29:22 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=34643>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34643





------- Additional Comments From hauser@acm.org  2005-05-11 15:29 -------
Created an attachment (id=14994)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=14994&action=view)
patched SSLAuthenticator.java

Thanks to Bill for the help to get it kind of working without the need to
configure a realm - how to do this:
A) compile the attached and place it in
tomcat/server/classes/org/apache/catalina/authenticator/ such that the
class-loader finds it before the same one in the catalina.jar
B) the web.xml's <auth-constraint> better has a nested
     <role-name>*</role-name>
otherwise despite a successful hand-shake, the access control will fail the
process
C) Till now, my browsers (MSIE6 and firefox1.0.3) after one successful login
can always login again despite configuring my CSP to prompt for password upon
each access to the private key. I attempted to force a re-handshake every time
and tried to avoid a server-side caching of the principal/certs, but I didn't
succeed so far. Closing the browser after logoff avoids the problem.
No clue - perhaps the server is clean and it is the browsers that cache the
certs as long as the socket lives due to the HTTP-keep-alive. If it were the
servers fault, I guess it would be adequate that a session.invalidate() would
also wipe the certs from a previous cert-based authentication.
D) If you have multiple private keys and corresponding certificates in your
brower's certificate store, the browsers do not offer any self-signed certs to
use for client-cert-auth. Haven't tried the remedies brain-stormed in comment 3
item 3, but my suspicion is that this is rather due to browser side
implementation.


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


Mime
View raw message