Windows LDAP API: No connection over SSL

Question

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?

Is the LDAP server actually listening on LDAP_SSL_PORT, which is probably port 636? — Andrew Henle
I think so. I first tried to connect over SSL using the ancient and no longer maintained Netscape C API and the NSS libraries. It succeeded on port 636. — klth
Do you have access to openssl? If so, run openssl s_client -connect host:636, replacing host with the actual hostname or IP address of your LDAP server. That should tell you the specific protocol and cipher suite used in the connection - maybe your server and Windows client don't have a common set there. You can also run openssl s_client -connect host:636 | openssl x509 -text to dump the server's certificate in a readable format. — Andrew Henle
Also, check the server's certificate that you installed on the Windows client. Go to "Internet Options->Content->Certificates->Trusted Root Certification Authorities" (where you installed your server's cert). Select your server's cert and click on the "Advanced" button. (That's what it is on my Windows 7 laptop) Make sure the proper certificate purposes are selected. IIRC "Server Authentication" is the important one, but there may be others. Look at some certificates from actual trusted authorities to see. — Andrew Henle
@andrew You advised to examine the "server’s certificate" on the client. I installed the CA on the client in the "Trusted Root etc." but not the server cert. Do you mean that? The CA that is installed on the client has the "Server Authentication" property set. I ran the openssl commands you suggested on both the server and the client. The output is identical apart from the value of "Master-key". So why is LDAPAdmin able to connect over SSL and a client program on the same computer is not? Does the Windows LDAP libraries expect the certs somewhere else or in a different form? — klth

klth klth · Accepted Answer · 2016-06-01T07:56:46

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.

Windows LDAP API: No connection over SSL

1 Answers