<div dir="ltr"><div class="gmail_default" style="font-family:courier new,monospace">Sorry for the delayed response but I needed to get a parallel setup going with the Shib v3.<br><br>I'm not quite sure I understand though. I thought setting idp.authn.LDAP.sslConfig = jvmTrust means we don't need to load a trust certificate or keystore file as we a are using the java default trust store. However If I comment out idp.authn.LDAP.trustCertificates the resolver wont start because it's is not set to anything. Should we not need set that attribute if we are using jvmTrust?<br><br></div><div class="gmail_default" style="font-family:courier new,monospace">for example I "thought" the following would be a valid config:<br>idp.authn.LDAP.sslConfig = jvmTrust<br>#idp.authn.LDAP.trustCertificates = /no/file/needed<br>#idp.authn.LDAP.trustStore = /no/file/needed<br></div><div class="gmail_default" style="font-family:courier new,monospace"><br></div><div class="gmail_default" style="font-family:courier new,monospace">I may just be misunderstanding jvmTrust. In essence we want to rely on java's own trust store because we use "real" certificates from Komo and we don't want to have to remember to reset the ldap certificate file when the ldap cert is replaced.<br></div><div class="gmail_default" style="font-family:courier new,monospace"><br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><font face="courier new, monospace">Jeffrey E. Crawford<br>ITS Application Administrator (IdM)<br>831-459-4365<br><a href="mailto:jeffreyc@ucsc.edu" target="_blank">jeffreyc@ucsc.edu</a></font><div><font face="courier new, monospace"><br></font></div><div><font face="courier new, monospace">Both pilots and IT professionals require training and currency before charging into clouds!<br></font></div><div><font face="courier new, monospace">---------------------------------------</font></div></div></div></div>
<br><div class="gmail_quote">On Mon, May 11, 2015 at 11:08 AM, Cantor, Scott <span dir="ltr"><<a href="mailto:cantor.2@osu.edu" target="_blank">cantor.2@osu.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 5/11/15, 1:57 PM, "Cantor, Scott" <<a href="mailto:cantor.2@osu.edu">cantor.2@osu.edu</a>> wrote:<br>
<br>
>On 5/11/15, 1:09 PM, "Jeffrey Crawford" <<a href="mailto:jeffreyc@ucsc.edu">jeffreyc@ucsc.edu</a>> wrote:<br>
><br>
>>The first scenario is sort of hit or miss so let me figure that one out, but the second issue trying to use the resolver is pretty consistent:<br>
>><br>
>>In ldap.properties<br>
>>idp.authn.LDAP.sslConfig                        = jvmTrust<br>
>>idp.authn.LDAP.trustCertificates                = %{idp.home}/credentials/ldap-server.crt<br>
>><br>
>>However ldap-server.crt file doesn't exist:, then excecute:<br>
>>shibboleth-idp/bin/reload-service.sh -id shibboleth.AttributeResolverService<br>
><br>
>That should happen on start up anyway, it shouldn't take a reload.<br>
<br>
</span>I just tested with a resolver connector using that property with the property set to a non-existent file, and the IdP starts but with a failed resolver service, no reload involved.<br>
<br>
If you want to fail outright, change the failFast property on that service.<br>
<br>
It's behaving as designed as far as I can see, modulo the question of whether we can accomodate comment it out, which is much harder.<br>
<div class="HOEnZb"><div class="h5"><br>
-- Scott<br>
<br>
--<br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.net</a><br>
</div></div></blockquote></div><br></div>