You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Luciana Moreira Sa de Souza Signed by - PrivaSphere AG <si...@privasphere.com> on 2009/11/11 16:24:45 UTC
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.
Re: How to set up tomcat and truststore
Posted by Bill Barker <bi...@verizon.net>.
"Luciana Moreira Sa de Souza Signed by - PrivaSphere AG"
<si...@privasphere.com> wrote in message
news:4AFAEAD4.30204@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: How to set up tomcat and truststore
Posted by Luciana Moreira Sa de Souza Signed by - PrivaSphere AG <si...@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?
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.
RE: How to set up tomcat and truststore
Posted by Jorge Medina <jm...@e-dialog.com>.
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: moreira@privasphere.com [mailto:moreira@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org