On 4/13/11 8:00 PM, Aaron Richton wrote:
On Wed, 13 Apr 2011, Judith Flo Gaya wrote:As the server is a rhel6 its openldap is compiled against openssl, the clients are using openldap with moznss, so it looks like I'll be forced to recompile everything to either moznss or openssl but it looks very very complicated.My experience differs. I know that I have F14 clients (and probably others; clients are largely out of my scope) using NSS, even though I don't have NSS on the servers. I'm not sure if somewhere in this thread you mentioned that you were (or weren't) using generally-respected commercial CAs? We do, and a working F14 client has: [/etc/openldap/ldap.conf says] TLS_CACERT /etc/pki/tls/cert.pem and /etc/pki/tls/cert.pem is a symlink to "certs/ca-bundle.crt" which has, unsurprisingly, a bunch of CA certs--I note no base64 encoding. Apparently these are both provided by a Fedora "ca-certificates" package.
I see, I also have those files that you mention...I created my own CA as lots of tutorials explain.. Then I transmitted it to the clients and used it in the ldap.conf file. Do you suggest me to send those to the server and use them instead of the ones I generated with openssl?
What's your server?
Well my final problem were not ldapsearch but the user autenticacion. The ldapsaerch showed the whole ldap definitions but if I try to ssh with an ldap user to the machine, I get some TLS negotiation problem ;( That's when I was told that the problem may be caused by the implementation of the ldap client (with moznss support).All this is to say...I've seen the OpenLDAP NSS client work at least once, via ldapsearch(1), even though it's not the TLS implementation on the server side.
Thanks a lot for your comments, looks like I'm definitely doing something wrong although I can't find out what ;(