<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 5:30 PM, Brent Putman wrote:<br>
</div>
<blockquote cite="mid:55833869.9030807@georgetown.edu" type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
<blockquote
cite="mid:20150618210901.GK889@praenomen.mgt.hawaii.edu"
type="cite">
<pre wrap="">
So this should work? Should I be looking elsewhere than the wildcard
cert for the source of the error?
javax.net.ssl.SSLPeerUnverifiedException: SSL peer failed hostname validation for name: null</pre>
</blockquote>
<br>
Like I said in my other note, this seems probably to be a bug on
our end due to unexpected behavior of Java Secure Sockets
Extensions (JSSE). Can you confirm what exact version and vendor
of Java you are running, and on what OS?<br>
<br>
If you can supply me with the actual metadata URL, I will attempt
to reproduce.<br>
</blockquote>
<br>
Nevermind, I was able to trivially reproduce using some SSL socket
testing code I have lying around.<br>
<br>
Good news, it looks like the underlying cause here is simply that
this particular server is not sending the correct intermediate cert
in the cert chain it returns. According to the cert path that
Firefox successfully builds, the intermediate is not the one they
are sending. (Looks like my Firefox probably has it cached from
somewhere else, so not getting from the wire).<br>
<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>
<br>
In any case, one fix is to add the correct intermediate certificate
to Java's cacerts trust store. This allows the PKIX path
construction to succeed and resolves the error for me. I'm attaching
the intermediate cert. You can add it to your JRE's
jre/lib/security/cacerts like so:<br>
<br>
<tt>keytool -importcert -keystore cacerts -storepass changeit -alias
idpgodaddyintermediate -file godaddy-firefox-inter-ca.crt</tt><tt><br>
</tt><tt><br>
</tt><br>
Alternatively, if you have some contact with the people running the
web server, you might just ask them to fix the cert chain that they
are sending.<br>
<br>
<br>
--Brent<br>
<br>
</body>
</html>