RE: How to set up tomcat and truststore
Doesn't accepting any certificate defeats the purpose of authentication? If you want to accept any certificate, then you are not doing any authentication. If you have written your own Realm, then do the verification on your realm against your dynamic truststore. -Original Message- From: more...@privasphere.com [mailto:more...@privasphere.com] On Behalf Of Luciana Moreira Sa de Souza Signed by - PrivaSphere AG Sent: Wednesday, November 11, 2009 10:25 AM To: users@tomcat.apache.org Cc: Ralf Hauser Subject: How to set up tomcat and truststore Hello, In the platform I am currently working on, we have to set up tomcat to require client certificate authentication. The main difference from the standard settings as described in (http://tomcat.apache.org/tomcat-5.5-doc/ssl-howto.html) is that we wish to accept any client certificates, including self-signed ones. The main reason for that is that we perform a second verification on the application layer as our truststore is dynamic. We have a JAASRealm class extension which basically extends the hasResourcePermission method setting it to always return true. Bellow you can see the configuration we added to the server.xml Realm className=com.privasphere.privalope.security.auth.ClientCertInAppRealm debug=99/ Nevertheless, I believe this method is only called after the initial handshake and after the client certificate has been accepted or refused (this is a guess). In addition, I am not entirely sure of what I should put in the truststoreFile property. As we want to accept all certificates this file would probably be empty. Any suggestions or best practices for this problem? Best regards, Luciana Moreira -- This message has been signed by the PrivaSphere Mail Signature Service. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: How to set up tomcat and truststore
Hi Jorge, thx for your quick reply. Maybe I did not explain my problem well enough, so let me elaborate it a bit more. In our platform clients can upload their self-signed certificates to allow them to login to our platform. If we add all client certificates to the static truststore file as per |truststoreFile| of http://tomcat.apache.org/tomcat-5.5-doc/ssl-howto.html#Edit%20the%20Tomcat%20Configuration%20File we end up having a scalability problem during handshake. This happens since the server must inform which client certificates issuers are accepted by the server, so having 50'000 self-signed DNs concatenated as a string doesn't really vouch for a quick TLS handshake. This is the reason why we do a second level authentication in our own realm implementation or the application layer against our own dynamic truststore. But for this to be possible, an initial handshake must occur where the client provides his certificate to the platform. So, we split authentication into two steps: i) establish a secure tunnel without the harmful renegotiation to someone ii) once that is done, ensure the someone is who we like without the need for TLS-renegotiation On the application layer we can get the client certificate chain through: X509Certificate certs[] = (X509Certificate[]) request.getAttribute(org.apache.catalina.Globals.CERTIFICATES_ATTR); And then we validate it against our own truststore. The main problem is reaching this stage with any client certificate. So my question is: 1) is the above mentioned |truststoreFile| attribute mandatory or not? 2) is there a way to tell the JSSESupport class not to send the issuer-DN list, but a wildcard for any issuer? (perhaps this could just be a * in the |truststoreFile| attribute, anyway it would be great to know whether this is a mandatory attribute or an optional one == pls document in the above cited howto.html) Best regards, Luciana Moreira -- This message has been signed by the PrivaSphere Mail Signature Service. smime.p7s Description: S/MIME cryptographic signature
Re: How to set up tomcat and truststore
Luciana Moreira Sa de Souza Signed by - PrivaSphere AG s...@privasphere.com wrote in message news:4afaead4.30...@privasphere.com... Hi Jorge, thx for your quick reply. Maybe I did not explain my problem well enough, so let me elaborate it a bit more. In our platform clients can upload their self-signed certificates to allow them to login to our platform. If we add all client certificates to the static truststore file as per |truststoreFile| of http://tomcat.apache.org/tomcat-5.5-doc/ssl-howto.html#Edit%20the%20Tomcat%20Configuration%20File we end up having a scalability problem during handshake. This happens since the server must inform which client certificates issuers are accepted by the server, so having 50'000 self-signed DNs concatenated as a string doesn't really vouch for a quick TLS handshake. This is the reason why we do a second level authentication in our own realm implementation or the application layer against our own dynamic truststore. But for this to be possible, an initial handshake must occur where the client provides his certificate to the platform. So, we split authentication into two steps: i) establish a secure tunnel without the harmful renegotiation to someone ii) once that is done, ensure the someone is who we like without the need for TLS-renegotiation On the application layer we can get the client certificate chain through: X509Certificate certs[] = (X509Certificate[]) request.getAttribute(org.apache.catalina.Globals.CERTIFICATES_ATTR); And then we validate it against our own truststore. The main problem is reaching this stage with any client certificate. So my question is: 1) is the above mentioned |truststoreFile| attribute mandatory or not? It is mandatory if you want to use the default JSSE connector. It's not needed if you use the APR connector, and set SSLVerifyClient=optionalNoCA (see http://tomcat.apache.org/tomcat-5.5-doc/apr.html for more details). However, this prompts for a cert the first time that the client connects, and there is currently no option to ask for a cert later if they don't supply one on the initial connection. 2) is there a way to tell the JSSESupport class not to send the issuer-DN list, but a wildcard for any issuer? (perhaps this could just be a * in the |truststoreFile| attribute, anyway it would be great to know whether this is a mandatory attribute or an optional one Not to my knowledge. The JSSESupport class entirely relies on the underlying JSSE in the JVM. It doesn't touch the SSL layer by itself. It might be possible to implement a custom TrustManagerFactory that does this, but I haven't looked into it. == pls document in the above cited howto.html) Best regards, Luciana Moreira -- This message has been signed by the PrivaSphere Mail Signature Service. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
