Error retrieving metadata: SSLPeerUnverifiedException

Brent Putman putmanb at georgetown.edu
Thu Jun 18 17:01:31 EDT 2015


Scott already said most of what I was going to say about: 1) wildcards
should work 2) no *secure* way to fix.  If the metadata is signed, then
you could add disregardSslCertificate="true" and add the signature
validation filter to verify the signature.

As a workaround, you could of course run a cron job, etc to download the
metadata to the local filesystem, and then use the filesystem metadata
provider against that.

But more importantly:


On 6/18/15 3:48 PM, Baron Fujimoto wrote:
>
> ERROR [org.opensaml.saml2.metadata.provider.HTTPMetadataProvider] Error retrieving metadata
> from https://meta.example.com/foo-metadata.xml
> javax.net.ssl.SSLPeerUnverifiedException: SSL peer failed hostname validation for name: null

Hmmm, it's odd that the hostname there in the message is null.  That's
being pulled straight out of the SSLSocket's SSLSession#getPeerHost(),
which I didn't think could be null...

That is indeed the actual value that is being passed into the
HostnameVerifier, so since it's null, that's never going to work.  I'm
pretty sure that's the root of the problem.

At first glance, and comparing to how this stuff works in HttpClient 4.x
and IdP v3, this looks like it might be a bug on our end, a mistake with
our use of the JSSE API.  Interesting though that no one has reported a
bug here in the 2 years since we did this fix for HttpClient 3.x's total
lack of hostname verification:

https://issues.shibboleth.net/jira/browse/JOWS-39




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20150618/ad8f7c6d/attachment.html>


More information about the users mailing list