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.

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to