<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
Hi Scott & Micheal,
<div class=""><br class="">
</div>
<div class="">First thank you for your help and input it pointed me in the right direction. The problem I was having was cert based. My AD cert didn’t have the proper info in the Subject or Subject Alternative Name fields. Which brings me to my current problem</div>
<div class=""><br class="">
</div>
<div class="">I have created a new cert on my AD server with the DNS name as the subject (shows up as CN=<a href="http://ADServer1.addomain.fdu.edu" class="">ADServer1.addomain.fdu.edu</a>) and the Subject Alternative Name is the DNS and SPN names. I have
multiple DCs configured in a round robin DNS. What seems to be happening is when the cert is being verified JAAS tries to validate the hostname against all of the servers in the SAN (including each member of the round robin up to the first 3 responses) and
then fails even though it finds a match.</div>
<div class=""><br class="">
</div>
<div class="">
<div class="">2015-09-01 20:51:45.613 - DEBUG [edu.vt.middleware.ldap.ssl.DefaultHostnameVerifier:127] - Verify with the following parameters:</div>
<div class="">2015-09-01 20:51:45.613 - DEBUG [edu.vt.middleware.ldap.ssl.DefaultHostnameVerifier:128] - hostname =
<a href="http://ADServer1.addomain.fdu.edu" class="">ADServer1.addomain.fdu.edu</a></div>
<div class="">2015-09-01 20:51:45.614 - DEBUG [edu.vt.middleware.ldap.ssl.DefaultHostnameVerifier:129] - cert = CN=<a href="http://ADServer1.addomain.fdu.edu" class="">ADServer1.addomain.fdu.edu</a></div>
<div class="">2015-09-01 20:51:45.614 - DEBUG [edu.vt.middleware.ldap.ssl.DefaultHostnameVerifier:202] - verifyDNS using subjectAltNames = [ADDOMAIN,
<a href="http://addomain.fdu.edu" class="">addomain.fdu.edu</a>, <a href="http://ADServer1.addomain.fdu.edu" class="">
ADServer1.addomain.fdu.edu</a>]</div>
<div class=""><font color="#b51a00" class="">2015-09-01 20:51:45.615 - DEBUG [edu.vt.middleware.ldap.ssl.DefaultHostnameVerifier:210] - verifyDNS found hostname match:
<a href="http://ADServer1.addomain.fdu.edu" class="">ADServer1.addomain.fdu.edu</a></font></div>
<div class="">2015-09-01 20:51:45.854 - DEBUG [edu.vt.middleware.ldap.ssl.AggregateTrustManager:75] - invoking checkServerTrusted for sun.security.ssl.X509TrustManagerImpl@14ef752</div>
<div class="">2015-09-01 20:51:45.855 - DEBUG [edu.vt.middleware.ldap.ssl.AggregateTrustManager:75] - invoking checkServerTrusted for edu.vt.middleware.ldap.ssl.HostnameVerifyingTrustManager@f8f387</div>
<div class=""><br class="">
</div>
<div class="">
<div class="">2015-09-01 20:51:46.457 - DEBUG [edu.vt.middleware.ldap.ssl.DefaultHostnameVerifier:127] - Verify with the following parameters:</div>
<div class="">2015-09-01 20:51:46.457 - DEBUG [edu.vt.middleware.ldap.ssl.DefaultHostnameVerifier:128] - hostname =
<a href="http://ADServer1.addomain.fdu.edu" class="">ADServer1.addomain.fdu.edu</a></div>
<div class="">2015-09-01 20:51:46.457 - DEBUG [edu.vt.middleware.ldap.ssl.DefaultHostnameVerifier:129] - cert = CN=<a href="http://ADServer2.addomain.fdu.edu" class="">ADServer2.addomain.fdu.edu</a></div>
<div class="">2015-09-01 20:51:46.458 - DEBUG [edu.vt.middleware.ldap.ssl.DefaultHostnameVerifier:202] - verifyDNS using subjectAltNames = [ADDOMAIN,
<a href="http://addomain.fdu.edu" class="">addomain.fdu.edu</a>, <a href="http://ADServer6.addomain.fdu.edu" class="">
ADServer6.addomain.fdu.edu</a>]</div>
<div class="">2015-09-01 20:51:46.681 - DEBUG [edu.vt.middleware.ldap.jaas.LdapLoginModule:164] - Error occured attempting authentication</div>
<div class="">javax.naming.PartialResultException: null</div>
</div>
<div class=""><br class="">
</div>
<div class="">
<div class="">Caused by: javax.naming.CommunicationException: simple bind failed:
<a href="http://DomainDnsZones.addomain.fdu.edu" class="">DomainDnsZones.addomain.fdu.edu</a>:636</div>
<div class=""><br class="">
</div>
<div class="">Caused by: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: Hostname '[<a href="http://ADServer1.addomain.fdu.edu" class="">ADServer1.addomain.fdu.edu</a>]' does not match the hostname in the server's certificate</div>
</div>
<div class=""><br class="">
</div>
<div class="">Caused by: java.security.cert.CertificateException: Hostname '[<a href="http://ADServer1.addomain.fdu.edu" class="">ADServer1.addomain.fdu.edu</a>]' does not match the hostname in the server's certificate</div>
<div class=""><br class="">
</div>
<div class="">Not sure what my cert should look like for my environment. </div>
<div class=""><br class="">
</div>
<div class="">Please advise,</div>
<div class=""><br class="">
</div>
<div class="">-Chris</div>
<div class=""><br class="">
</div>
<div class="">PS not sure where <a href="http://DomainDnsZones.addomain.fdu.edu" class="">
DomainDnsZones.addomain.fdu.edu</a>:636 is coming from.</div>
</div>
<div class=""><br class="">
</div>
<div class=""><br class="">
</div>
<div>
<blockquote type="cite" class="">
<div class="">On Aug 3, 2015, at 1:40 PM, Cantor, Scott <<a href="mailto:cantor.2@osu.edu" class="">cantor.2@osu.edu</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">On 8/3/15, 1:37 PM, "users on behalf of Michael O Holstein" <<a href="mailto:users-bounces@shibboleth.net" class="">users-bounces@shibboleth.net</a> on behalf of
<a href="mailto:michael.holstein@csuohio.edu" class="">michael.holstein@csuohio.edu</a>> wrote:<br class="">
<blockquote type="cite" class=""><br class="">
As I understood his question, he's not talking about the business of authenticating *peers* inside the IDP, he's getting the error from the ldaptive library because the self-signed cert that AD servers generate for their LDAPS isn't understood by the java crypto
API. <br class="">
</blockquote>
<br class="">
Yes, that was my understanding.<br class="">
<br class="">
<blockquote type="cite" class="">I suppose you could invoke Tomcat (or Jetty) with an explicit keystore that wasn't the generic system root (meaning it'd only use it for that process) and that keystore could be the same as the IDP .. but I've never seen such
a think suggested outside manually declaring a keystore just to sort our this kind of problem (eg: is it the Oracle one I'm using? or the OpenJDK one?, or the Debian one? ...)<br class="">
</blockquote>
<br class="">
The IdP has no requirement for relying on the Java root store in any capacity.<br class="">
<br class="">
<blockquote type="cite" class="">IMHO there is a good way around this problem .. if you have multiple AD servers you can use something like ha-proxy with a 20year self-signed cert out the front and the -ignore option out the back .. so you don't have to fuss
with it every year. Of course there are other ways, but that is the cheap one.<br class="">
</blockquote>
<br class="">
Indeed, any server (other than web) should use a long-lived, self-signed certificate.<br class="">
<br class="">
-- Scott<br class="">
<br class="">
-- <br class="">
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net" class="">
users-unsubscribe@shibboleth.net</a><br class="">
</div>
</blockquote>
</div>
<br class="">
</body>
</html>