I have a Subversion server running on Ubuntu 11.04 using Apache, and I'm trying to hook the authentication up with LDAPS. I got the Apache config file set up to authenticate against LDAP (sans the S) just fine, but the secured version is giving me... problems. Apparently it's a certificate issue. Unfortunately I'm a certificate n00b.
I found this question, which appears to be the same problem I'm getting. I tried putting the LDAPVerifyServerCert off
line in my httpd.conf, and it worked--but I don't think I want to just ignore the certificate if it's got problems, do I?
I think our LDAP server has a self-signed cert... maybe you can start by confirming or denying that for me. Here's what I get when I run openssl s_client -connect myldap.xyz.edu:636 -showcerts
:
CONNECTED(00000003)
depth=0 /CN=myldap.xyz.edu
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 /CN=myldap.xyz.edu
verify error:num=27:certificate not trusted
verify return:1
depth=0 /CN=myldap.xyz.edu
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
0 s:/CN=myldap.xyz.edu
i:/DC=edu/DC=xyz/CN=myldap
-----BEGIN CERTIFICATE-----
[certificate here]
-----END CERTIFICATE-----
---
Server certificate
subject=/CN=myldap.xyz.edu
issuer=/DC=edu/DC=xyz/CN=myldap
---
Acceptable client certificate CA names
/DC=edu/DC=xyz/CN=myldap
[...]
---
SSL handshake has read 13738 bytes and written 289 bytes
---
New, TLSv1/SSLv3, Cipher is RC4-MD5
Server public key is 1024 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : RC4-MD5
Session-ID: [...]
Session-ID-ctx:
Master-Key: [...]
Key-Arg : None
Start Time: 1335300252
Timeout : 300 (sec)
Verify return code: 21 (unable to verify the first certificate)
I copied the certificate from this output (from the BEGIN line through the END line), pasted it into /etc/ssl/certs/myldap.xyz.edu.pem
, ran c_rehash
, and tried openssl s_client -connect myldap.xyz.edu:636 -CAfile /etc/ssl/certs/myldap.xyz.edu.pem -showcerts
. No luck. It gave me the same exact errors.
Here's my httpd.conf file:
ServerName svnserver.xyz.edu
<Location />
DAV svn
SVNParentPath /var/svn
SVNPathAuthz off
AuthName "Subversion server"
AuthType Basic
AuthBasicProvider ldap
AuthzLDAPAuthoritative off
AuthLDAPBindDN "ldap_bind_dn@xyz.edu"
AuthLDAPBindPassword "[password]"
AuthLDAPURL "ldaps://myldap.xyz.edu/DC=xyz,DC=edu?sAMAccountName?sub?(objectClass=*)" NONE
Require ldap-user user1 user2
</Location>
The LDAP server is Active Directory running on Windows Server 2008, if I'm not mistaken. I'm not really in a position to mess with it, and I don't think I should need to--we're already using it just fine in a whole bunch of places. There's got to be something wrong on the client side. I've been looking around Google for three days with no luck. So, anyone who can 1) solve the problem, 2) point me to a different question with a solution, or 3) link to a tutorial would be extremely appreciated. :^)
EDIT:
Here are the commands & results that I ran per chutz's suggestion:
root@svnserver:~# openssl x509 -noout -issuer_hash < /etc/ssl/certs/myldap.xyz.edu.pem
505d0f30
root@svnserver:~# openssl x509 -noout -hash < /etc/ssl/certs/myldap.xyz.edu.pem
1045bba3
So the hash and the issuer hash are different, meaning it's not self-signed. I think I'm understanding a bit better now. At first I didn't realize that the entities /CN=myldap.xyz.edu
and /DC=edu/DC=xyz/CN=myldap
are seen as two separate things, even though they refer to the same machine. So I've got the certificate for the former, but I now need the certificate for the latter, correct? I'll see what my boss can tell me (he's the AD admin).
EDIT #2:
I got the issuer certificate, put it in /etc/ssl/certs/myldap1.pem
, and ran c_rehash. I made sure to check the hashes, and myldap1.pem
showed both subject and issuer hashes of 505d0f30
, the same as the issuer of my myldap.xyz.edu
cert. So I tried the openssl s_client
command again. At first, it gave me the same set of errors, but once I remembered to add the -CAfile
option, it came back instead with
Verify return code: 10 (certificate has expired)
Ah, excellent. Turns out, my certificate has an expiration date in 2009. >_< Well, at least we've gotten to a problem we know how to solve. Thanks for all your help!