<div dir="ltr"><div dir="ltr"><div dir="ltr">HA! Scott's hint didn't do the trick but eventually led me to what I believe is the root cause:</div><div dir="ltr">AD team rotating the private certs being presented, and me not having the current ones.<br></div><div dir="ltr"><br></div><div dir="ltr">Replacing StartTLSTrustCredential with  <br>





<p class="gmail-p1" style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;line-height:normal;font-family:Menlo"><span style="color:rgb(165,119,5)"><span class="gmail-s1" style="color:rgb(189,54,19)">trustFile=</span>"/opt/shibboleth-idp/credentials/UA_AD_CA.pem"</span><font color="#2176c7"> </font></p><p class="gmail-p1" style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;line-height:normal;font-family:Menlo"><font color="#000000">invalidated the data connector configuration:</font></p><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><font face="monospace, monospace" size="1"><span class="gmail-s1" style="font-variant-ligatures:no-common-ligatures">Error creating bean with name 'uaADLDAP': Invocation of init method failed; nested exception is net.shibboleth.utilities.java.support.component.ComponentInitia<br></span><span class="gmail-s1" style="font-variant-ligatures:no-common-ligatures">lizationException: Data Connector 'uaADLDAP': Invalid connector configuration<br></span><span class="gmail-s1" style="font-variant-ligatures:no-common-ligatures">...<br></span><span class="gmail-s1" style="font-variant-ligatures:no-common-ligatures">Caused by: net.shibboleth.idp.attribute.resolver.dc.ValidationException: [org.ldaptive.provider.ConnectionException@1397767450::resultCode=null, matchedDn=null, responseControls=null, referralURLs=null, messageId=-1, message=javax.net.ssl.SSLHandshakeException: sun.security.valid<br></span><span class="gmail-s1" style="font-variant-ligatures:no-common-ligatures">ator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target, providerException=javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path<br></span><span class="gmail-s1" style="font-variant-ligatures:no-common-ligatures"><span class="gmail-Apple-converted-space"> </span>building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target]</span></font></blockquote><div><br></div><div>That's pretty much the process error I was seeing with prior valid but non-functional data connector config. So that made me question validity of the certs I refer to. Back to the directory browser to uncover the cert being presented, and whaddayaknow: new certs being presented. I exported and added those new certs into the .pem file and TLS connections restored.<br>(Leaving the mystery of why my directory browser and the jaas authentication had continued to work...some weird long-lived cached trust?)</div><div><br></div><div>Of course if actually had the private CA that signs these revolving AD certs life would run smoother, as the Shibb wiki wisely warns:<br></div></div></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><div><div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">Assuming ldap-over-TLS (ldaps) or StartTLS is used, you SHOULD (and, in a future version of the software, MUST) configure the rules for validating the LDAP server's TLS key within the connector. It is possible to leave this to the Java runtime by relying on default behavior, but this will result in warnings as of V3.3.2 and will cease to function in V4.0, as this <a href="https://shibboleth.net/community/advisories/secadv_20171004.txt" class="external-link" rel="nofollow" style="color:rgb(50,96,186);text-decoration-line:none">advisory</a> outlines.</blockquote></div></div></div><div><div><div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">There are generally two ways to do this:</blockquote></div></div></div></blockquote><div><div><div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><ul style="margin:10px 0px 0px;color:rgb(23,43,77);font-family:-apple-system,system-ui,"Segoe UI",Roboto,Oxygen,Ubuntu,"Fira Sans","Droid Sans","Helvetica Neue",sans-serif;font-size:14px"><ul><li>Reference a CA (Certificate Authority) that has signed the certificate chain presented by the LDAP server.</li></ul></ul><ul style="margin:10px 0px 0px;color:rgb(23,43,77);font-family:-apple-system,system-ui,"Segoe UI",Roboto,Oxygen,Ubuntu,"Fira Sans","Droid Sans","Helvetica Neue",sans-serif;font-size:14px"><ul><li>Reference the LDAP server's certificate explicitly.</li></ul></ul></blockquote></div></div></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><div><div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">The latter provides better security but likely will require constant updating and coordination with the LDAP server's operational staff unless it relies on a longer-lived certificate.</blockquote></div></div></div><div><div><div><a href="https://wiki.shibboleth.net/confluence/display/IDP30/LDAPConnector">https://wiki.shibboleth.net/confluence/display/IDP30/LDAPConnector</a></div></div></div></blockquote><div dir="ltr"><div dir="ltr"><div><br></div><div>but I've been unable so far to pry that CA cert from our AD team. </div><div><br></div><div>David Bantz</div><div><br></div><p class="gmail-p1" style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;line-height:normal;font-family:Menlo">






</p><p class="gmail-p1" style="margin:0px;font-variant-numeric:normal;font-variant-east-asian:normal;font-stretch:normal;font-size:11px;line-height:normal;font-family:Menlo;color:rgb(0,0,0)"><span class="gmail-s1" style="font-variant-ligatures:no-common-ligatures">







</span></p></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 25, 2019 at 11:43 AM Cantor, Scott <<a href="mailto:cantor.2@osu.edu">cantor.2@osu.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I would have to guess you have to be mistaken about them using the same certificate on different ports; but FWIW you should use the simple trustFile="..." syntax in place of all that extra XML from the security namespace to just reference a certificate file.<br>
<br>
I have no problems making the same CA work for both scenarios in my configuration now. If trustFile works and the old syntax doesn't, then possibly there's a bug there.<br>
<br>
-- Scott<br>
<br>
<br>
<br>
-- <br>
For Consortium Member technical support, see <a href="https://wiki.shibboleth.net/confluence/x/coFAAg" rel="noreferrer" target="_blank">https://wiki.shibboleth.net/confluence/x/coFAAg</a><br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net" target="_blank">users-unsubscribe@shibboleth.net</a><br>
</blockquote></div>