Suddenly, yesterday, one of my apache servers became unable to connect to my LDAP (AD) server. I have two sites running on that server, both of which use LDAP to auth against my AD server when a user logs in to either site. It had been working fine two days ago. For reasons unknown, as of yesterday, it stopped working. The error log only says this:

auth_ldap authenticate: user foo authentication failed; URI /FrontPage [LDAP: ldap_simple_bind_s() failed][Can't contact LDAP server], referer: http://mysite.com/

I thought perhaps my self-signed SSL cert had expired, so I created a new one for mysite.com, but not for the server hostname itself, and the problem persisted. I enabled debug-level logging. It shows the full SSL transaction with the LDAP server, and it appears to complete without errors until the very end when I get the "Can't contact LDAP server" message. I can run ldapsearch from the commandline on this server, and I can login to it, which also uses LDAP, so I know that the server can connect to and query the LDAP/AD server. It is only apache that cannot connect.

Googling for an answer has turned up nothing, so I'm asking here. Can anybody provide insight to this problem?

Here's the LDAP section from the apache config:

<Directory "/web/wiki/">
    Order allow,deny
    Allow from all
    AuthType Basic
    AuthName "Login"
    AuthBasicProvider ldap
    AuthzLDAPAuthoritative off
    #AuthBasicAuthoritative off
    AuthLDAPUrl ldaps://domain.server.ip/dc=full,dc=context,dc=server,dc=name?sAMAccountName?sub
    AuthLDAPBindDN cn=ldapbinduser,cn=Users,dc=full,dc=context,dc=server,dc=name
    AuthLDAPBindPassword password
    require valid-user
  • Funny enough, I had one Apache 2 server that authenticated against LDAP which was working fine for months, then just last week started exhibiting this exact same problem! I can't for the life of me figure out what it is, I've tried all sorts of things. Going to watch this question. – Kamil Kisiel Nov 6 '09 at 0:23

14 Answers 14


A packet trace from the httpd server/LDAP client revealed a message about the CA being unknown.

TLSv1 Alert (Level: Fatal, Description: Unknown CA)

I found and added the following option to my httpd.conf:

  LDAPVerifyServerCert          off

That fixed my issue under CentOS 6. The CentOS 5 httpd servers did not require any modification and had worked all along without the option.

  • This answer jut won me a beer. A colleague ran into this issue and I happened to overhear him complaining about why his newly minted Debian server could not connect to our LDAP server. I IM'd him this link and his problem was immediately solved. – dmourati May 10 '13 at 0:17
  • Plus many. This answer really saved my hide. – AnrDaemon Aug 12 '16 at 20:33

I have had an issue similar to this before with AD on Windows 2003: the solution I found was to not bind using the full DN but instead use the user@domain syntax:

AuthLDAPBindDN user@domain.com

Do you have access to the logs from your LDAP server? They might be helpful in troubleshooting this problem.

  • LDAP server is actually a Windows AD server. I checked in the event logs, didn't find anything useful. Not even any indication that the apache server even tried to connect. – SethG Oct 5 '09 at 15:08
  • You should verify that the Apache server is actually sending the LDAP request to the AD server; it's possible that something is preventing the LDAP request from making it to the AD server at all. If you have enough privileges on the Windows machine, you can run Wireshark to verify that the LDAP request is actually making its way to AD properly. If it isn't, then check network and firewalls in between the two servers. Are you running iptables on the Apache server? – Eric Dennis Oct 8 '09 at 16:48

I've seen this when a package update causes changes in the client ldap.conf (usually /etc/ldap.conf or /etc/openldap/ldap.conf) and resets the TLS_REQCERT option to a more stringent setting. It can negotiate the SSL properly, but will still fail at the end as it can't validate the certificate chain from a trusted root.


You might want to check the clock of the servers. If the time difference is more than a couple of minutes, the authentication ticket will be invalid.

Although this is not exactly the error message, the 'the other server suddenly gets the same problem' part might indicate such a problem.


You need to impoert the LDAP CA certificate to work with LDAPS


I have a similar problem, which I've identified by running this command:

openssl s_client -connect $ldap_host:636 -state -nbio 2>&1. I think mod_ldap uses openssl underneath, so this should be fairly consistent for debugging.

I compared it against another SSL encrypted server I knew was working. A properly verified SSL connection will show a chain going to a root CA and return 0. A failure of SSL verification will give a number and reason. You can use the output to determine what's going wrong.

In my case, the LDAP server certs are signed by Verisign, which uses Intermediate CA certs. OpenSSL is unable to verify the cert and the connection is refused ("connection refused by server" is unhelpful).


I had a similar problem. I could get the cert with openssl, I could query Active Directory over SSL with ldapsearch on the same ports. Finally I changed to the Microsoft Global Catalog ports 3268 or 3269 and they both worked. The Microsoft Windows 2003 servers had been patched, but that happened days before the problems started occurring.


I was implementing LDAPS across all of our servers and also ran into this problem. Does it go away if you revert to plaintext LDAP (Not ideal, but useful to know the source of the problem). If so, I have yet to find a solution, but perhaps together we can isolate a bug in authnz_ldap.


I'm assuming that your command-line experiments were using the same "bind user" as in your apache configs. If not, you should check that you have the correct current password.

In the past, I once had to use the global catalog port instead of the standard LDAP port for the AD domain. I can't remember the reason why. For ldaps as in your url above, this would be port 3269.


The way this works is that your website needs to connect to AD using the credentials of your bind user first, and then, once this connection is made, it uses this access to validate the credentials of the user attempting to access your website.

According to your error message, it sounds like the process is unable to connect to AD as your bind user (AuthLDAPBindDN).

Ensure that the bind user account is not disabled in Active Directory, and that the password you have specified as (AuthLDAPBindPassword) is correct. Also, ensure that your bind user has the necessary permissions to lookup other users (has to be a member of Domain Users in our case)


I have just had this problem ("can't contact ldap server") on RHEL6, and it was the result of changes to openldap. yum had updated the config file /etc/openldap/ldap.conf but instead of overwriting it (in case it was customised; in my case it wasn't) it created an ldap.conf.rpmnew file.

Copying the .rpmnew version over ldap.conf fixed the issue.

(I can't agree that turning off certificate verification is an answer to this. It avoids the problem in a potentially dangerous manner.)


I managed to fix this problem by installing the berkelydb and openldap packages found here.

The difference is that RedHat has started linking things against nss instead of openssl for SSL support. In this case, that breaks all the things. Installing these packages (which are linked against openssl) fix the problem. Just get the packages and run:

yum install berkeleydb-ltb* openldap-ltb*

Then restart apache, and you should be in business.


I had an identical problem after upgrading from rhel6.6 to rhel7.5. When I was out of ideas I concluded the mod_ssl on apache 2.2.32 may not be 100% compatible on rhel7.4. I upgraded from Apache 2.2.32 to Apache2.4, enable SSL, and sldap worked.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.