Bug 34868

AFAIK, Bill's and Mario's LDAP-based trustStore will not do because I assume
their solution would be able to validate a self-signed certificate, but they'll
never receive a self-signed cert from the browser. But perhaps this is due to
the issue that Mario's implementation is rather a Realm than really a
Truststore, and Bill really had an implementation of a
javax.net.ssl.X509TrustManager in mind?
http://jakarta.apache.org/tomcat/tomcat-5.5-doc/ssl-howto.html#Edit%20the%20Tomcat%20Configuration
File appears to be rather file-oriented than ldap or JDBC oriented...

one option to avoid this scalability problem would be to add a few
no-questions-asked ca's such as http://www.black-helicopter.org/bh (not really
updated anymore) and perhaps http://cacert.org could do this
(http://lists.cacert.org/cgi-bin/mailman/private/cacert/2005-June/003095.html)

this issue might even receive academic attention:
http://www.infsec.ethz.ch/education/projects/sa_phishing.ps

I'would suggest a solution which uses a javax.net.ssl.X509TrustManager that
trusts all client certificates. So it is possible to accept untrusted
certificates and specially self-signed certifactes. The actual authentication
can then be done by a servlet.

I've implemented it such that the use of this AllTrustingX509TrustManager can be
configured in the server.xml by setting the attribute
"acceptUntrustedCertifcates" for the connector. If then attribute is set to
"true", then in the initialization of the JSSESocketFactory the actual
TrustManager will be wrapped in the AllTrustingX509TrustManager and the
SSLContext will be initialized with it.
Further I've added the new method isClientCertificateTrusted() to SSLSupport
which returns if the client certificate is trusted with respect to the actual
TrustManager. The method can be accessed from a servlet through the new Request
attribute "javax.servlet.request.ClientCertificateTrusted".

Created two patches for Tomcat 5.5.13. One for the connectors module and one for
the catalina module.

Created attachment 17296 [details]
ssl-client-cert patch for the connectors module

Created attachment 17297 [details]
ssl-client-cert patch for the catalina module

Created attachment 17298 [details]
ssl-client-cert patch for the connectors module

fixed: added the files missing in the last patch

Created attachment 17299 [details]
client certificate authentication example

minimum example showing how client certificate authentication can be done after
applying my patches (see above)

Wouldn't it be nice to be able overrule the global truststores by a trustStore
object in the session?
I guess this would only require to enhance the
org.apache.tomcat.util.net.jsse.JSSESocketFactory.getTrustStore() to check for this.

This looks really useful. We want to integrate tomcat with PBAC
(http://www.gria.org/documentation/manual/pbac-2-manual/overview) to check
client certificates at the SSL layer rather than only at the SOAP message layer.
Did this fix or an equivalent solution ever get added to tomcat?

Per session trust managers can't possibly work since the SSL connection has to be established before the client can send any data that would identify the session in which to look for the trust manager. I am therefore resolving this as WONTFIX.

However, it is worth noting the Tomcat 7 (as a result of fixing bug 48208) now supports custom trust managers which should be sufficient to meet any requirement not meet by the standard trust manager.