<div dir="ltr"><div class="gmail_extra">On Thu, May 14, 2015 at 4:36 PM, Cantor, Scott <span dir="ltr"><<a href="mailto:cantor.2@osu.edu" target="_blank">cantor.2@osu.edu</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 5/14/15, 7:08 PM, "Jeffrey Crawford" <<a href="mailto:jeffreyc@ucsc.edu">jeffreyc@ucsc.edu</a>> wrote:<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.<br>
<br>
</span>It means the properties aren't used, it doesn't mean syntactically things load without them. To do that we would have to provide default values (which would be the same as what's in the file and be non-existent).<br>
<br>
Properties are not a panacea, and my general impression is that the ones that point to files don't work all that well because it becomes confusing to make them "optional".<br></blockquote><div><br><div class="gmail_default" style="font-family:courier new,monospace;display:inline">​Gotcha, it's more of a "limitation". Still learning the nuances of the new software, thanks for being patient :)<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
>However If I comment out idp.authn.LDAP.trustCertificates<br>
> 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>
</span>It doesn't matter what it's set to but unsetting it just isn't going to work. If you want to change the files so it does work, you can, but that's just extra work at this point.<br>
<br>
Of course, it matters very much what it's set to if you use a resolver file that actually references that property, which is what you were (apparently) doing.<br></blockquote><div><br><div class="gmail_default" style="font-family:courier new,monospace;display:inline">​Okay I didn't realized it was referenced in the example attribute-resolver.xml file until you pointed it out, seems so obvious now :)​</div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
>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>
<br>
</span>It's not, because there is no default value for those properties. If they're not set, it will blow up. This is just the reality. It doesn't matter whether it's good, bad, right, wrong. That's what it is at the moment.<br>
<span class=""><br>
>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>
<br>
</span>You don't have to. The trust material you put into the file that property is referring to is still the CA/chain, not the server cert, if that's what you want to do. It's a trust store, same as the cacerts file is. You should not use JVM trust in general and you don't gain anything from doing so, regardless of the rest of the issues. It's one-time configuration either way.​</blockquote><div> <br><div class="gmail_default" style="font-family:courier new,monospace">​I think you are suggesting to point the parameter to the OS CA bundle file which arguably would be updated as systems are patched, I originally assumed you meant manage the certificate file in the shibboleth credential location which even if you used the Root CA, you would have to update at some point in large intervals of time, risking an outage as it becomes invalid in several years.<br><br></div><div class="gmail_default" style="font-family:courier new,monospace">I'm still curious about your statement though, I figure the JVM is updated very frequently due to security concerns so the cacerts file would come along for the ride. So what are the issues with the JVM certificate store? <br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
-- Scott<br>
<br>
--<br></div></div></blockquote><div><br><div class="gmail_default" style="font-family:courier new,monospace;display:inline">​Jeffrey​</div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">
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></div>