Weblog entry #15 for lykwydchykyn
See all weblog entries made by lykwydchykyn.
The Debian boxes all log this error:
[LDAP: ldap_start_tls_s() failed][Connect error]
When I try doing an ldapsearch from the Debian boxes over TLS, I get this:
SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
The Apache documentation seems to suggest that I need to point to a certificate using something like LDAPTrustedGlobalCert, but I don't see the SLES servers doing this anywhere, and they appear to be working.
Can anyone give me a shove in the right direction here?
Comments on this Entry
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
If that won't help post some more verbose/debug output.
Cheers,
rjc
[ Parent | Reply to this comment ]
LDAPVerifyServerCert Off
Cesar Avalos.
[ Parent | Reply to this comment ]
[ Send Message | View dkg's Scratchpad | View Weblogs ]
LDAPVerifyServerCert Off is reasonable for debugging purposes (i.e. to see if it is the server certificate verification that's failing), it is a really bad idea for ongoing use. Presumably your goal in setting up encrypted traffic between these servers is to make sure that only the eDirectory server is capable of reading the traffic and providing authentication information. Setting LDAPVerifyServerCert Off means that you will not be able to ensure that the machine you're talking to is actually your specific eDirectory server. Any machine on the network path between the two machines could intercept the communications and perform a successful man-in-the-middle attack.
[ Parent | Reply to this comment ]
If bad certificates are the problem, then the really scary thing is that the SLES servers are NOT choking on this. I grepped the apache configs on the SLES boxes for any mention of ldap, and this directive is not anywhere in there. And yet, the SLES boxes are not complaining about the unverified certificate. And to think I was actually feeling bad about having used Debian on Friday...
[ Parent | Reply to this comment ]
[ Send Message | View dkg's Scratchpad | View Weblogs ]
So if the eDirectory server's certificate is signed by your company's certificate authority, and you have a copy of the certificate of your company's CA stored at /etc/ssl/certs/mycompany-CA-cert.pem, then the following directive should work in the relevant VirtualHost directive (where your other apache LDAP configuration directives go):
LDAPTrustedGlobalCert /etc/ssl/certs/mycompany-CA-cert.pemIf your organization is using one of the big, traditional CAs, and you have the
ca-certificates package installed, and you actually trust all the big, traditional CAs to not screw you over, you should be able to just use: LDAPTrustedGlobalCert /etc/ssl/certsIt's probably a good idea to read the "Using SSL/TLS" section of the apache
mod_ldap documentation as well.
[ Parent | Reply to this comment ]
Actually, I believe the certificate I downloaded was a b64 file, or maybe a .der (I tried this a couple of different ways). I specified something like:
LDAPTrustedGlobalCert BASE_64 /path/to/the/cert/file
As was suggested in the "Novell SDK" section of the documentation. I assume I'm using the novell sdk, since this is eDirectory.
Believe me, I've read, re-read, and re-re-read that section of the mod_ldap documentation. It means less every time I read it. Nothing against the documentation, I just seem to be dense when it comes to this stuff.
[ Parent | Reply to this comment ]
[ Send Message | View dkg's Scratchpad | View Weblogs ]
I assume I'm using the novell sdk, since this is eDirectory.I might be reading the docs wrong, but i think you're mistaken here. Debian's
libapache2-mod-authz-ldap appears to be based on the OpenLDAP codebase, not the Novell SDK. Just because the remote machines are running Novell doesn't mean that your local interoperable TLS implementation is using their software. If you want to see the entire certificate chain, you can do something like this (assuming LDAPS, not STARTTLS over a normal LDAP session):
openssl s_client -showcerts -connect your.ldap.server:636This will show you the full certificate chain offered by the server (and the certs will be in a form that OpenSSL is comfortable with). Usually, all certificates but the root certificate will be in that chain. Look for the Issuer of the last certificate listed. For example, if there are 3 certificates offered, the last certificate might show the following Subject and Issuer:
3 s:/C=US/ST=UT/L=Salt Lake City/O=The USERTRUST Network/OU=http://www.usertrust.com/CN=UTN-USERFirst-Hardware i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA RootIf that's the case, then the certificate you'd be looking for is the certificate for
AddTrust External CA Root. Debian ships this in ca-certificates as /etc/ssl/certs/AddTrust_External_Root.pem, but if you weren't sure where to find that cert, you can also look up the subject names of all the certificates shipped like this: for cert in /etc/ssl/certs/*.pem; do echo $cert openssl x509 -text -noout < $cert | grep Subject: done(note that i'm not advocating for the use of this CA; i don't know anything about them, but they came up when i tried looking at a domain that i knew shipped a relatively long certificate chain)
[ Parent | Reply to this comment ]
LDAPVerifyServerCert Off does not fix the problem. I still continue to get the same error in the apache log: [LDAP:ldap_start_tls_s() failed][connect error]
I've set the apache logging level to 'debug', but that's the most I can get apache to tell me.
I've been trying to connect using STARTTLS, I don't really know the difference, but it worked with STARTTLS on SLES so that's why I've been trying to use it here. I thought I've located the root CA certificate, and I've put that in LDAPTrustedGlobalCA as you suggested. It still errors out.
Is there a different command to locate the root cert for TLS? I played around with openssl s_client, but I could only get it to report SSL certs.
[ Parent | Reply to this comment ]
[LDAP:ldap_simple_bind_s() failed][can't contact LDAP server]
This is with (what I believe to be) the root CA certificate added with the LDAPTrustedGlobalCA directive. The question is, if we have self-signed certificates in the chain (as we appear to), is there any way I'm going to get this to work on the apache end? Or do I need the network admins to sort out the certificate issues?
[ Parent | Reply to this comment ]