Error retrieving metadata: SSLPeerUnverifiedException
baron at hawaii.edu
Thu Aug 27 21:18:54 EDT 2015
On Thu, Aug 27, 2015 at 08:20:53PM +0000, Cantor, Scott wrote:
>On 8/27/15, 4:14 PM, "users on behalf of Baron Fujimoto" <users-bounces at shibboleth.net on behalf of baron at hawaii.edu> wrote:
>>We now log the slightly different error with an IP addr instead of null
>>javax.net.ssl.SSLPeerUnverifiedException: SSL peer failed hostname validation for name: 184.108.40.206
>You're hitting Java's shiny new bug, discussed at length a few weeks ago on the list.
Urgh, ok thanks. For reference, I think I found that here:
>What JVM is it?
JVM Version: 1.8.0_51-b16
Search results seem to indicate the bug was introduced with this update
same as 1.7.0_85.
>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:
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'shibboleth.RelyingPartyConfigurationManager': Invocation of init method failed; nested exception is edu.internet2.middleware.shibboleth.common.service.ServiceException: Configuration was not loaded for shibboleth.RelyingPartyConfigurationManager service, error creating components.
Caused by: org.xml.sax.SAXParseException: cvc-complex-type.3.2.2: Attribute 'disregardTLSCertificate' is not allowed to appear in element 'MetadataProvider'.
>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?
Baron Fujimoto <baron at hawaii.edu> :: UH Information Technology Services
minutas cantorum, minutas balorum, minutas carboratum desendus pantorum
More information about the users