tomcat native/APR connector for SOAP requests / resolvertest

[Peter Schober]

Two unrelated questions, but very much related for me atm.

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.

The reason I ask (instead of confirming myself with the IdP at hand)
is that the institution the IdP is for recently changed their
canonical DNS domain and now the visible hostname (also changed in ACS
URLs, which probably was ill-advised, as it never surfaces to end user
visibility) does not match the trust fabric cert's hostname
(auto-generated by the IdP installer), which breaks resolvertest/libcurl:

$ echo "" | openssl s_client -connect idp.someuni.edu:8443 2>&1 | fgrep subject=
subject=/CN=idp.some-uni.edu

$ resolvertest -n foo -i https://idp.some-uni.edu/idp/shibboleth
-saml2 -f urn:oasis:names:tc:SAML:2.0:nameid-format:transient
2012-02-27 18:53:11 ERROR Shibboleth.AttributeResolver.Query :
exception during SAML query to
https://idp.someuni.edu:8443/idp/profile/SAML2/SOAP/AttributeQuery:
CURLSOAPTransport failed while contacting SOAP endpoint
(https://idp.someuni.edu:8443/idp/profile/SAML2/SOAP/AttributeQuery):
SSL: certificate subject name 'idp.some-uni.edu' does not match
target host name 'idp.someuni.edu'
2012-02-27 18:53:11 ERROR Shibboleth.AttributeResolver.Query : unable
to obtain a SAML response from attribute authority

I'll have to regenerate the IdP's credentals sooner than later (the
passphrase to the JKS has been lost, one reason for my dabbling with
the Tomcat native APR connector, which allows direct use of the PEM
encoded idp.{crt,key} credentials from the filesystem, which are not
passphrase-protected -- just like when fronting Tomcat with httpd) at
which point this problem will of course disappear.

I just thought I'd ask if preventing libcurl from performing any such
checks on trust fabric certs in resolvertest might be a. possible and
b. generally desirable.
-peter