<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
<div class="moz-cite-prefix">On 6/18/15 6:34 PM, Brent Putman wrote:<br>
</div>
<blockquote cite="mid:5583478A.2030104@georgetown.edu" type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
<br>
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. <br>
<br>
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.<br>
</blockquote>
<br>
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. <br>
<br>
For the archives: Just noting that if you see:<br>
<br>
<tt>javax.net.ssl.SSLPeerUnverifiedException: SSL peer failed
hostname validation for name: null</tt><br>
<br>
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.<br>
<br>
Setting
<meta http-equiv="content-type" content="text/html;
charset=windows-1252">
<tt>javax.net.debug=all </tt>will provide all the gory details of
what failed.<br>
<br>
<a class="moz-txt-link-freetext" href="https://issues.shibboleth.net/jira/browse/JOWS-44">https://issues.shibboleth.net/jira/browse/JOWS-44</a><br>
</body>
</html>