idp.authn.LDAP.sslConfig set to jvmTrust odity

[Cantor, Scott]

> I'm been playing around with IdP v 3.1.1 and was trying to get the ldap
> configuration in ldap.properties to work. I rather use the java default cacerts

It's a Java bug that that file even exists, so no, I don't think you should use that, and we want to make that a bad option to choose.

> but trying to set idp.authn.LDAP.sslConfig=jvmTrust has been making the
> software kinda go haywire.

Notwithstanding the above, you should file bugs on that, nothing you posted makes much sense to me, so there must be bugs in the property usage.

> I thought I should just comment out the "idp.authn.LDAP.trustCertificates"
> and "idp.authn.LDAP.trustStore" elements but then the server wouldn't start
> with:
> 
> Could not resolve placeholder 'idp.authn.LDAP.trustCertificates' in string
> value "%{idp.authn.LDAP.trustCertificates}"

Also bugs, IMHO, we have very few properties that should be required.

> I finally just made a copy of the ldap certificate in ldap-server.crt and went
> back to idp.authn.LDAP.sslConfig = certificateTrust and finally everything
> quieted down. However we use real certificates in our ldap server so there is
> no reason for us to need to keep a copy around. Am I missing something
> here?

There is really no such thing as a "real" certificate. Server to server trust should always be explicitly keyed, there's no reason to do anything else, and a ton of good reasons not to. You get better security and no need to constantly change keys or certificates. But even if you chose to use PKIX, the trust anchors used should always be application-specific, not global.

-- Scott