tomcat native/APR connector for SOAP requests / resolvertest

[Peter Schober]

* Chad La Joie <lajoie at itumi.biz> [2012-02-27 20:10]:
> On Mon, Feb 27, 2012 at 13:48, Peter Schober <peter.schober at univie.ac.at> wrote:
> > I've set up a new IdP for someone and noticed that the Tomcat Native
> > http://tomcat.apache.org/tomcat-6.0-doc/apr.html accepts an
> > SSLVerifyClient parameter with "optionalNoCA" as an argument.
> > Can anyone comment on whether this may or may not be usable instead
> > of the DelegateToApplication extension (or fronting Tomcat with
> > httpd)?
> > I don't know if that passes though all necessary data (the public key
> > itself, mainly) since I didn't see a corresponding "ExportCertData"
> > SSLOption, which mod_ssl provides.
> 
> To the best of my knowledge it is usable.  We haven't ever recommended
> it before because it only works on systems for which the library is
> compiled, requires special configuration, and I don't think can be
> paired with client-cert auth.  To keep from fragmenting the docs we
> just went with a solution that works everywhere.  In addition, in this
> case, the native connector is actually *slower* than the Java version
> because all that OptionalNoCA does it turn off the failure mode when
> the check fails, it does not turn off the actual check (or at least
> didn't the last time we looked).

OK, thanks. I'll look into this further (once I get a chance to renew
the trust fabric credentials) and I'm aware of the limited use (or
usabliity) of using the apr libs within the servlet container. In the
aforementioned (rather peculiar) situation it just seemed the easiest
way out (e.g. pre-existing PEM key pair for the webserver, so no need
to force the private key into a JKS, etc.).
Also, speed differences between native and Java implementations is of
no concern in this situation (disabling queries is currently most
likely). Thanks for the heads up.
-peter