idp.authn.LDAP.sslConfig set to jvmTrust odity

[Cantor, Scott]

On 5/15/15, 1:27 PM, "Jeffrey Crawford" <jeffreyc at ucsc.edu> wrote:
>
>​Gotcha, it's more of a "limitation". Still learning the nuances of the new software, thanks for being patient

We're still trying to figure out how the properties should be handled, and it's an active area of discussion. My first reaction was that commenting out the files should work, and then I realized commenting out the idp.signing.key property won't work either, but the only difference is that every IdP has a signing key while not every IdP uses this property. We don't know what the right answer is, but I'm inclined to think we need to be able to comment out properties that people don't use.

> 
>​I think you are suggesting to point the parameter to the OS CA bundle file which arguably would be updated as systems are patched

You can point the parameter at the CA your LDAP server happens to be using. If that's going to change constantly, then I guess you have more problems, but you should still be explicit about it and load a trust store for *that* function and not do some kind of global thing, if for no other reason than for explicit control and self-documentation. "What is this connection secured by? Oh, it's right here..."

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

Well, what you *should* do is use a self-signed cert on any non-browser-facing endpoint, and load that exact certificate as the anchor, because without that, you have no reasonable revocation mechanism.

But what I was saying was that you could load that CA, yes. If it expires, your connection *should* break. The problem is that people are treating LDAP servers like web servers, and that's not the same use case at all.

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

The JVM list is as contaminated as your browser's is, for one thing.

-- Scott