IdP 3.1.0.1 TLS problems

[Dave Bartholomew]

> doing that would render the intermediate a trust anchor with no regard
for anything above it

OK, that makes sense, but wouldn't account for the behavior (upon IdP
restart) I'm seeing if I understand you correctly.

In addition to an ldapserver.school.edu cert which is "targeted" by
idp.authn.LDAP.ldapURL, AD also has a <hostname>.school.edu cert (also
signed by InCommon) which has myad.school.edu listed as a SAN and also
entered during installation as the AD domain (that's the only "connection"
I can make that might make the IdP care about the <hostname>.school.edu
cert).

When I started the IdP, I got following:
Data Connector 'myLDAP': Invalid connector configuration
hostname of the server 'ldapserver.school.edu' does not match the hostname
in the server's certificate
No subject alternative DNS name matching ldapserver.school.edu found.

The ldapserver.school.edu cert does have itself listed as a SAN (and CN),
but the <hostname>.school.edu cert doesn't have ldapserver.school.edu
listed as a SAN.

So, I figured I'd delete the <hostname>.school.edu cert to see what
happens after which I got the following error:

providerException=javax.naming.ServiceUnavailableException: [LDAP: error
code 52 - 00000000: LdapErr: DSID-0C090E17, comment: Error initializing
SSL/TLS, data 0, v1db1]; remaining name '']

After restoring the <hostname>.school.edu cert, I still got the above
error while I was expecting to get the first error.

I would expect the IdP to use the idp.authn.LDAP.ldapURL in its
certificate checking, but am I missing some other dependencies?
Any clues in unscrambling this would be appreciated.

Dave Bartholomew
Cal State University, East Bay
ITS
Dave.Bartholomew at csueastbay.edu
(510) 885 - 2324