Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am trying to get ldaps to work through Apache 2.2.17 (Windows Server 2008). If I use ldap (plain text) my configuration works great.

LDAPTrustedGlobalCert CA_DER C:/wamp/certs/Trusted_Root_Certificate.cer
LDAPVerifyServerCert Off
<Location />
    AuthLDAPBindDN "CN=corpsvcatlas,OU=Service Accounts,OU=u00958,OU=00958,DC=hca,DC=corpad,DC=net"
    AuthLDAPBindPassword ..removed..
    AuthLDAPURL "ldaps://,dc=corpad,dc=net?sAMAccountName?sub"
    AuthType Basic
    AuthBasicProvider ldap
    AuthUserFile /dev/null
    require valid-user

I also tried the other encryption choices besides CA_DER just to be safe, with no luck.

Finally, I also needed this with Apache tomcat. For tomcat I used the tomcat JRE and ran a line like this:

keytool -import -trustcacerts -keystore cacerts -storepass changeit -noprompt -alias mycert -file Trusted_Root_Certificate.cer

After doing the above line ldaps worked greate via tomcat. This lets me know that my certificate is a-ok.

Update: Both ldap modules are turned on, since using ldap instead of ldaps works fine.

When I run a git clone this is the error returned:

C:\Temp>git clone http://eqb9718@localhost/git/Liferay.git
Cloning into Liferay...
error: The requested URL returned error: 500 while accessing http://eqb9718@loca
fatal: HTTP request failed

access.log has this: - eqb9718 [23/Nov/2011:18:25:12 -0600] "GET /git/Liferay.git/info/refs service=git-upload-pack HTTP/1.1" 500 535 - eqb9718 [23/Nov/2011:18:25:33 -0600] "GET /git/Liferay.git/info/refs HTTP/1.1" 500 535

apache_error.log has nothing. Is there any more verbose logging I can turn on or better tests to do?

Update 2: I can run wireshark on the apache server and I can clearly see the outgoing connection but I can't really make heads or tails of anything else. I'm no wireshark guru, just looks like jargon.

Also, I used ldap browser to verify that ldaps is working great from the machine.

Update 3: I turned apache logging to debug and this is the error coming back:

[3016] auth_ldap authenticate: user eqb9718 authentication failed; URI /git/Liferay.git/info/refs [LDAP: ldap_simple_bind_s() failed][Server Down]

Now keep in mind that on this same Server 2008 machine I can use LDAP Browser to connect via ldaps to port 3269 and nothing is "down". What is that error telling us?

Update 4: Here are the results from running openssl s_client -connect 3269 -showcerts:

I have also tried the openssl command going directly to a domain controller on port 636 which works and I have tried it in my httpd.conf which produces the same error. I don't know if it is important to note that when I go directly to a controller (389 or 636) I have to add a container to the url like ou=group,dc=hca,etc. That makes using the GC a must. Must be a bug in mod_ldap since I found that solution from many other posts.

Update 5: I started up apache manually instead of via a service and this is the ldap debug that is printing out:

[Thu Nov 24 19:19:08 2011] [debug] util_ldap.c(1769): LDAP: SSL verify server ce
rtificate - FALSE
[Thu Nov 24 19:19:08 2011] [debug] mod_authnz_ldap.c(1010): [3144] auth_ldap url
parse: `ldaps://,dc=corpad,dc=net?sAMAccountName?s  
ub?(objectClass=*)', Host:, Port: 3269, DN: dc=hca,dc=cor
pad,dc=net, attrib: sAMAccountName, scope: subtree, filter: (objectClass=*), con
nection mode: using SSL
share|improve this question

Your LDAPVerifyServerCert Off is rendering the trusted root configuration inert - so trust is not an issue.

Are there really that number of spaces in OU=Service Accounts?

And do you have mod_ldap and mod_authnz_ldap enabled?

If neither of those are the issue, can you check your error logs for anything useful?

share|improve this answer
There are not that many spaces, it is just a problem when I pasted it in here. Both of those apache modules are enabled. Keep in mind when I change it from ldaps to ldap:// and the port to 3268 it works great over plain text. I also verified throug tomcat that ldaps works fine too. I will update the above post with logs and more information. – pcm2a Nov 24 '11 at 0:27
I have added some more debug logging information. – pcm2a Nov 24 '11 at 16:29
@user101956 Verify that the 3269 listener is working properly as an SSL listener, and actually presenting a certificate (I've seen cases where these listeners stay up but stop presenting a cert) - openssl s_client -connect -showcerts. Also, any particular reason that you're using the global catalog instead of the normal listener? Maybe try 636. – Shane Madden Nov 24 '11 at 18:05
The connection using openssl (or LDAP Browser) works fine. I will update my above post with a link to the output of that ( The Active Directory group tells me to use the GC, I assume for redundancy. However, I have tried pointing to one specific controller on port 636 and get the same error. – pcm2a Nov 24 '11 at 21:04
Hrm. Maybe try against ldap://...:3268 with LDAPTrustedMode TLS to get it throwing a STARTTLS on that connection instead? The only other thing I can think of is a cert validation issue - can you verify that the trusted cert is in DER and not PEM format? And maybe try turning LDAPVerifyServerCert back to On? – Shane Madden Nov 25 '11 at 3:00

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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