Hi @all thanks for your help, I solved the problem. So There where two things which causes this problem:
* Thanks to Dameon: Java clients can't handle Multi-Domain Certificates: So the ldap1.spsc.tugraz.at was a alias on servXXX..... and the Java client was not able to handle this. * Java clients can't handle new cipher suites. If the server provides a cipher suite which the Java client doesn't know, it will not ask again for another version of the cipher, it simply cuts the connection. So Thanks for your help after hours of debugging I came on this. Regadrs Andreas On 06/30/2015 01:17 PM, Dameon Wagner wrote: > On Tue, Jun 30 2015 at 12:48:22 +0200, Andreas Laesser scribbled > in "Problems with openLDAP + GSSAPI + JAVA": >> Hi @all >> >> I have a (maybe) a problem with my openldap server authenticating over a >> JAVA tool (Apache Directory Studio LDAP Browser V2.0.0.v20130628, >> jXplorer) via GSSAPI. >> >> When I do a ldapsearch from command line via GSSAPI it works fine... >> >> >> ~ % klist >> Ticket cache: FILE:/tmp/krb5cc_1086_lR4Nxxxxrs >> Default principal: [email protected] >> >> Valid starting Expires Service principal >> 30/06/2015 10:54 02/07/2015 10:54 krbtgt/[email protected] >> renew until 10/07/2015 10:54 >> 30/06/2015 10:54 02/07/2015 10:54 ldap/[email protected] >> renew until 10/07/2015 10:54 >> >> >> ~ % ldapsearch -H ldaps://ldap1.spsc.tugraz.at -b "dc=SPSC,dc=TUGRAZ,dc=AT" >> >> This works well.... >> >> but if I try the same from one of the two tools mentioned above it >> simply not bind or connects.... >> >> Does anybody had the same problems, or knows a solution? > > Hi Andreas, > > Just as a hunch, what's the subject (or Subject Alternative Names) for > the SSL certificate on "ldap1.spsc.tugraz.at"? If you're using DNS > round-robin I'm guessing that "ldap1.spsc.tugraz.at" may not be > listed, and that JAVA is being picky about validating the server-side > certificate. > > Just a thought. > > Cheers. > > Dameon. >
