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
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 "email@example.com" 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. :^)
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
/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).
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!