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 [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|document how to use |document how to use |certificate-based |certificate-based |"clientAuth" on a per user |"clientAuth" on a per user |or per session basis |or per session basis also | |with self-signed/expired | |client certs ------- Additional Comments From [EMAIL PROTECTED] 2005-05-09 23:49 ------- it appears that if the client certificate shall not be asked from all users and not upon the first contact with the given connector, the "clientAuth" attribute isn't it, irrespective of whether set to "true" or "want". The approach appears to be rather to direct the user to a protected jsp/struts action at the point in time you want the client cert auth to happen with <security-constraint> <web-resource-collection> <web-resource-name>Client Certificate Auth</web-resource-name> <url-pattern>/certBasedAuth.do</url-pattern> </web-resource-collection> <auth-constraint /> </security-constraint> <login-config> <auth-method>CLIENT-CERT</auth-method> </login-config> Being flexible with respect to the used certificate remains tricky: 1) if already knowing the certificate to be expected e.g. by virtue of it being in a LDAP truststore, it appears to be impossible to allow for mismatches of the certs[0].getSubjectDN().getName() without replacing the current org.apache.catalina.authenticator.SSLAuthenticator - one might for example rather use the SHA1 fingerprint to match? 2) similarly, if you want to be more tolerant on certificate expiration/not-yet-valid, I haven't figured how to get the "validate=false" for org.apache.catalina.realm.RealmBase.authenticate(X509Certificate[] certs) from a config file without altering sources. 3) As for self-signed certificates, I see two approaches a) be able to create a mini-trust-store on the fly before the ssl-handshake occurs in org.apache.tomcat.util.net.jsse.JSSESupport.handShake() - I have no clue how late in an SSLSocket's life its truststore can be altered? A nice example how this can be done a per thread basis (albeit before creating the socket and not when it's already in operation) is Oleg's org.apache.commons.httpclient.contrib.ssl.AuthSSLProtocolSocketFactory (see Bug 34391) - I guess this implies that the web-app programmer in some way (by means of an enhanced LoginConfig or an extra parameter of the method or a session attribute?) might tell org.apache.catalina.authenticator.SSLAuthenticator.authenticate() the self-signed cert it should expect when that method starts b) alternatively, a less rigid TrustManager might be used in org.apache.tomcat.util.net.jsse.JSSE15SocketFactory.getTrustManagers(String keystoreType, String algorithm) - some ideas are in http://forum.java.sun.com/thread.jspa?forumID=2&threadID=411937 -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]