<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
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.<br>
<br>
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.<br>
<br>
But more importantly:<br>
<br>
<br>
<div class="moz-cite-prefix">On 6/18/15 3:48 PM, Baron Fujimoto
wrote:<br>
</div>
<blockquote cite="mid:20150618194850.GI889@praenomen.mgt.hawaii.edu"
type="cite">
<pre wrap="">
ERROR [org.opensaml.saml2.metadata.provider.HTTPMetadataProvider] Error retrieving metadata
from <a class="moz-txt-link-freetext" href="https://meta.example.com/foo-metadata.xml">https://meta.example.com/foo-metadata.xml</a>
javax.net.ssl.SSLPeerUnverifiedException: SSL peer failed hostname validation for name: null</pre>
</blockquote>
<br>
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...<br>
<br>
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.<br>
<br>
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:<br>
<br>
<a class="moz-txt-link-freetext" href="https://issues.shibboleth.net/jira/browse/JOWS-39">https://issues.shibboleth.net/jira/browse/JOWS-39</a><br>
<br>
<br>
<br>
<br>
</body>
</html>