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
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 [EMAIL PROTECTED] 2005-05-11 15:29 --- Created an attachment (id=14994) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=14994action=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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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
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 [EMAIL PROTECTED] 2005-05-11 18:28 --- as per comment 4 item D), got (pseudo-)self signed certs working (it is not the browser's fault), i.e. I first created a self-signed (root9cert), signed the user-cert with it and imported the root-cert into the $JAVA_HOME/jre/lib/security/cacerts for tomcat. Since this doesn't scale as mentioned in and in the described in item 3 GUI/application control flow, the session may well exist before the CLIENT-CERT is executed: i) register trust-store with user-self-signed cert in session for the user to be authenticated as per Bug 34868 ii) response.sendRedirect(/certBasedAuth.do); now that trust-store would be effective upon the subsequent request doing the auth -- 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]
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
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-nameClient Certificate Auth/web-resource-name url-pattern/certBasedAuth.do/url-pattern /web-resource-collection auth-constraint / /security-constraint login-config auth-methodCLIENT-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=2threadID=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]
