"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

Reply via email to