CODEWITHSUNDEEP
cwindowssslldap
klth
klth

Reputation: 1

Windows LDAP API: No connection over SSL

I’m trying to connect to an LDAP directory over SSL using the Windows LDAP C-API. This fails with error code 0x51 = LDAP_SERVER_DOWN while the event log on the client computer has this: „The certificate received from the remote server does not contain the expected name. It is therefore not possible to determine whether we are connecting to the correct server. The server name we were expecting is eim-tsi2.sam.develop.beta.ads. The SSL connection request has failed. The attached data contains the server certificate.”

This is can’t be true since “Ldap Admin” is able to connect over SSL and port 636.

The LDAP directory is an Oracle DSEE which has the CA and the server certificate in the appropriate cert store. The client has the CA installed in the “Trusted Root Certification Authorities” and there in the „Local Computer“ physical store. I assumed this to be the right place for the CA since my little client program uses the Windows LDAP C-API; LDAP Admin indeed expects the CA there.

Here is an excerpt of my program omitting the error handling and other obvious source code:

   ld = ldap_sslinit(host, LDAP_SSL_PORT, 1);
   // Set options: LDAP version, timeout ...
   rc = ldap_set_option(ld, LDAP_OPT_SSL, LDAP_OPT_ON);
   // Now connect:
   rc = ldap_connect(ld, NULL);

Result: 0x51 = LDAP_SERVER_DOWN

Connecting without SSL succeeds so the LDAP server is generally accessible.

Since Ldap Admin is able to connect over SSL, I assume the certificates are valid and in the right place. But obviously the LDAP API expects them somewhere else and cannot get the server certificate from the server. I configured the certs as described here: https://msdn.microsoft.com/en-us/library/aa366105%28v=vs.85%29.aspx

What am I doing wrong?

Upvotes: 0

Views: 1559

Answers (1)

klth
klth

Reputation: 1

Sometimes it helps reading error messages more carefully. The entry in the event viewer caused by an unsuccessful bind over SSL was "The server name we were expecting is eim-tsi2.sam.develop.beta.ads."

I should have noticed that the name should have been eim-tsi2.cgn.de.(etc.), instead. So the domain name part was wrong.

This is a bug in Schannel which can be solved by an entry in the registry as described here: https://support.microsoft.com/en-us/kb/2275950.

I still do not know why LDAPAdmin was able to connect without that additional registry key although it also uses the WINLDAP API and therefore should have run into the same error. But that doesn’t matter any more.

Thanks, Andrew, for your help.

Upvotes: 0

Related Questions