Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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!

share|improve this question
    
What's the validation error on your openssl command that's specifying the -CAfile? –  Shane Madden Apr 25 '12 at 1:09
    
The same errors as without the -CAfile flag. I've edited the post to clarify that. Good catch on the lack of specificity. –  DLosc Apr 26 '12 at 21:13
    
Yup - dig the root certificate up. It should be exportable pretty easily when opening up the subject certificate in Windows (either a file export or in the certificates MMC snap-in). –  Shane Madden Apr 26 '12 at 21:25

1 Answer 1

up vote 1 down vote accepted

Yours is not a self-signed certificate. If it were, the following "Subject" and "Issuer" would have been identical.

Server certificate
subject=/CN=myldap.xyz.edu
issuer=/DC=edu/DC=xyz/CN=myldap

This is most likely the reason why you cannot properly get it verified - the certificate that openssl s_client -showcerts shows on the screen is not the CA certificate.

Just to double check, try running the following commands.

openssl x509 -noout -issuer_hash < /etc/ssl/....pem

openssl x509 -noout -hash < /etc/ssl/....pem

If the two hashes are different, then it is not a self-signed certificate. If that is the case (as I suspect) your only option would be to get the issuing CA certificate somehow. Try asking the Active Directory admins for it and do what you already did when you get it - dump it into /etc/ssl/certs and run c_rehash.

And when you get the certificate, do run openssl x509 -noout -hash and make sure it matches the -issuer_hash of the LDAP certificate.

share|improve this answer
    
Thanks for the answer--this clarified some things for me. See edit to original post. –  DLosc Apr 26 '12 at 21:14

Your Answer

 
discard

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.