Error retrieving metadata: SSLPeerUnverifiedException

[Baron Fujimoto]

On Fri, Aug 28, 2015 at 01:27:57AM +0000, Cantor, Scott wrote:
>On 8/27/15, 9:18 PM, "users on behalf of Baron Fujimoto" <users-bounces at shibboleth.net on behalf of baron at hawaii.edu> wrote:
>>
>>>Regardless you should be verifying the signtaure on the metadata and simply set the flag to disregard the TLS connection. That's the best choice.
>>
>>Is this supported in IdPv2? I found documentation of this attribute under
>>the IdPv3, but not for IdPv2. This error also suggests no:
>
>It was called disregardSslCertificate originally, I don't know if it was ever renamed on V2. I also thought it was named disregardTlsCertificate now, not TLS.

Ahh, thanks yes. disregardSslCertificate at
<https://wiki.shibboleth.net/confluence/display/SHIB2/IdPMetadataProvider#IdPMetadataProvider-FileBackedHTTPMetadataProvider>

And disregardTLSCertificate at
<https://wiki.shibboleth.net/confluence/display/IDP30/HTTPMetadataProviders>

>>>If you must, you can work around the bug, apparently by setting -Djdk.tls.trustNameService=true on the JVM.
>>
>>So assuming the best choice workaround is not an option, I guess that
>>leaves setting jdk.tls.trustNameService=true for the JVM?
>
>It is an option, but only if the file is actually signed obviously. Otherwise you can either roll back to an unbroken Java or use that override.

Roger, that. As it turns out in this case, I don't believe this metadata
at <https://meta.onecampus.com/myuh2.hawaii.edu.xml> is signed after all.
If it were, it should have <ds:Signature>...</ds:Signature> and associated
elements, no?  (Judging by the InCommon metadata as an example.)

Aloha,
-baron
-- 
Baron Fujimoto <baron at hawaii.edu> :: UH Information Technology Services
minutas cantorum, minutas balorum, minutas carboratum desendus pantorum