Error retrieving metadata: SSLPeerUnverifiedException

[Baron Fujimoto]

We received helpful advice a while back re an error we were encountering
attempting load and SP's metadata via http. The SP in question has
finally gotten around to updating their SSL certificate, but we're still
seeing a similar error.

For <https://meta.onecampus.com/myuh2.hawaii.edu.xml>:

Previously, they were missing an intermediate cert in their chain. E.g.:

 0 s:/OU=Domain Control Validated/CN=*.onecampus.com
   i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2
 1 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./CN=Go Daddy Root Certificate Authority - G2
   i:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority
 2 s:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority
   i:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority

Which resulted in
javax.net.ssl.SSLPeerUnverifiedException: SSL peer failed hostname validation for name: null

Now, their chain looks like this

 0 s:/OU=Domain Control Validated/CN=*.onecampus.com
   i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2
 1 s:/OU=Domain Control Validated/CN=*.onecampus.com
   i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2
 2 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2
   i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./CN=Go Daddy Root Certificate Authority - G2

[0] and [1] are duplicates, but I don't know if that's relevant.

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: 54.172.111.162

I've set javax.net.debug=all when invoking tomcat, but don't see anything
that looks obviously like and error for where it appears to be connecting
to onecampus.com.

I think we essentially see (excerpted):

catalina.out:
%% No cached client session
*** ClientHello, TLSv1.2
*** ServerHello, TLSv1.2
%% Initialized:  [Session-3, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384]
** TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
*** Certificate chain
chain [0] =
  Subject: CN=*.onecampus.com, OU=Domain Control Validated
  Issuer: CN=Go Daddy Secure Certificate Authority - G2, OU=http://certs.godaddy.com/repository/, O="GoDaddy.com, Inc.", L=Scottsdale, ST=Arizona, C=US
chain [1] =
  Subject: CN=*.onecampus.com, OU=Domain Control Validated
  Issuer: CN=Go Daddy Secure Certificate Authority - G2, OU=http://certs.godaddy.com/repository/, O="GoDaddy.com, Inc.", L=Scottsdale, ST=Arizona, C=US
chain [2] =
  Subject: CN=Go Daddy Secure Certificate Authority - G2, OU=http://certs.godaddy.com/repository/, O="GoDaddy.com, Inc.", L=Scottsdale, ST=Arizona, C=US
  Issuer: CN=Go Daddy Root Certificate Authority - G2, O="GoDaddy.com, Inc.", L=Scottsdale, ST=Arizona, C=US
***
Found trusted certificate:
  Subject: CN=Go Daddy Root Certificate Authority - G2, O="GoDaddy.com, Inc.", L=Scottsdale, ST=Arizona, C=US
*** ECDH ServerKeyExchange
*** ServerHelloDone
*** ECDHClientKeyExchange

It looks like we have a compatible TLS protocol and cipher. Any suggestions?

-baron

On Thu, Jun 18, 2015 at 08:02:42PM -0400, Brent Putman wrote:
>
>On 6/18/15 6:34 PM, Brent Putman wrote:
>>
>> So there's a fairly standard PKIX path validation error going on
>> here.  In my experience however this usually results in an IOException
>> being thrown in JSSE.  From what I can tell of the JSSE debug output,
>> however, it's not doing that here for some reason. It seems instead to
>> just be closing the socket and returning. Or maybe we're somehow
>> swallowing it that I'm not seeing.  Then our hostname verification
>> code runs unconditionally (expecting that an exception would have been
>> thrown if the socket wasn't ok), producing the spurious error above,
>> because the SSLSession is already closed/invalid. 
>>
>> So we likely might have a bug here in our socket factory, but perhaps
>> not the same one as I originally thought. Indeed a more trivial one.
>
>I opened the issue below for this.  Really this is just the case of a
>misleading error message being emitted.  I have applied a fix in svn.
>
>For the archives: Just noting that if you see:
>
>javax.net.ssl.SSLPeerUnverifiedException: SSL peer failed hostname
>validation for name: null
>
>it really means that the SSL handshake has failed, such as due to cert
>validation error, or possibly something else like no acceptable cipher
>suites, etc.  The actual exception in this case is being swallowed and
>handled internally.
>
>Setting javax.net.debug=all will provide all the gory details of what
>failed.
>
>https://issues.shibboleth.net/jira/browse/JOWS-44

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