'certificate verify failed' means that the certificate received from the remote side cannot be verified locally. This is usually because it's self-signed and not locally cached as a trusted certificate, but more generically means that it's not signed by a trusted CA. 'ldap_bind: Can't contact LDAP server' means that the connection was closed before LDAP could actually talk to the server to get the LDAP stuff. This logically follows from the 'certificate verify failed' error, because when the verification fails the client closes the connection.
What is your client? Where is it configured to look for its trusted certificates? Once you know that, you will also know where to put the self-signed certificate from the server to make it work. -Kyle H On Mon, Jul 28, 2008 at 3:19 PM, John Oliver <[EMAIL PROTECTED]> wrote: > I have been beating my head against this for says. I've followed a > dozen HOWTOs and blogs I've found. Nothing is working. > > I'm looking for a simple HOWTO that includes all of the little details > that nobody ever includes, because once you know them they're just too > painfully obvious :-) This file must be chowned to these permissions, > that file must be owned by this owner, etc. > > To add to my frustration, I made this work twice! Yes! I had created a > simple self-signed certificate, nothing fancy. It works on one of my > servers. It's just another that I cannot get working. I'm sure that > part of my problem is I just don't know how to troubleshoot this... I > get very generic error messages like > "routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed" and > "ldap_bind: Can't contact LDAP server" that probably have deeper > meanings. > > Part of my problem is, this is working with a self-signed certificate on > one server. I did not need to copy a CA to clients. I can copy an > ldap.conf and an nsswitch.conf to a new client, and it just works. I'd > really like to do the same thing (yes, even though everyone is hollering > about how that's a terrible idea, it can't possibly work, I'm a complete > idiot for wanting to do it, etc.) on the other server... I want them to > be as similar as possible, so if one breaks, I don't have to remember > all of the differences between the two. > > If I can get to the point of being able to get certificates working > "correctly", with a CA and all, great... but I have to be able to get > back to a working config instantly if that fails, and right now, since I > haven't the faintest idea in the world why one server works perfectly > and the other has resisted every one of dozens of attempts, I'm honestly > afraid to mess with the working one. > > -- > *********************************************************************** > * John Oliver http://www.john-oliver.net/ * > * * > *********************************************************************** > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-users@openssl.org > Automated List Manager [EMAIL PROTECTED] > ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
