idp.authn.LDAP.sslConfig set to jvmTrust odity

Jeffrey Crawford jeffreyc at ucsc.edu
Fri May 15 13:27:44 EDT 2015


On Thu, May 14, 2015 at 4:36 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:

> On 5/14/15, 7:08 PM, "Jeffrey Crawford" <jeffreyc at ucsc.edu> wrote:
> >
> >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.
>
> 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).
>
> 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".
>

​Gotcha, it's more of a "limitation". Still learning the nuances of the new
software, thanks for being patient :)

>
> >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?
>
> 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.
>
> 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.
>

​Okay I didn't realized it was referenced in the example
attribute-resolver.xml file until you pointed it out, seems so obvious now
:)​


>
> >for example I "thought" the following would be a valid config:
> >idp.authn.LDAP.sslConfig = jvmTrust
> >#idp.authn.LDAP.trustCertificates = /no/file/needed
> >#idp.authn.LDAP.trustStore = /no/file/needed
>
> 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.
>
> >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.
>
> 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.​


​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.

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?

>
> -- Scott
>
> --
>

​Jeffrey​


> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20150515/09cfd370/attachment.html>


More information about the users mailing list