[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: [SOLVED] Re: Slapd, GNUTLS on Debian/Squeeze



On 05/23/2011 08:39 AM, David Dumortier wrote:

Le sam. mai 21 2011 ï 12:55:03 -0300, Reinaldo de Carvalho dit :

On Sat,  May 21, 2011 at 12:04 PM, David Dumortier<d.dumortier@free.fr>  wrote:


I suspect you are running ldap:// on port 636.


ldapsearch -W -H ldap://myip:636/
ldap_result: Can't contact LDAP server (-1)



No, -H ldaps://myip:636/ (to SSL/ldaps).


Tried it with same result :-(



You're really using a Certificate file (and not a CSR)?

Ldap client will  validade the server certificate, you should especify
TLS_CACERT /to/file or TLS_REQCERT never on /etc/ldap/ldap.conf


You are right, I modified TLS_REQCERT in slapd conf but not on
/etc/ldap/ldap.conf.


I can not believe this. That's absolutely wrong. Why use certificates, when client is setup to ignore them?
Correct solution is to add Your certificatin authority to trusted cert store.
Since on debian, openldap is compiled with gnutls, this lines from manual apply:
man ldap.conf:

TLS_CACERT <filename>
              Specifies the file that contains certificates for all  of
              the Certificate Authorities the client will recognize.
TLS_CACERTDIR <path>
              Specifies  the path of a directory that contains Certifiâ
              cate Authority certificates in separate individual files.
              The TLS_CACERT is always used before TLS_CACERTDIR.  This
              parameter is ignored with GNUtls. On Debian  openldap  is
              linked against GNUtls.

So, just put Your authority cert to some file, point TLS_CACERT to it and it should work.
One more thing, when using SSL/TLS it is necessary to use FQDN of the server, which must be same as CN of
certificate. (or storing server's IP as CN, not too portable).
so this is wrong: ldapsearch -W -H ldaps://192.168.0.1:636/
and this is correct: ldapsearch -W -H ldaps://myserver.mydomain.com:636/

I never tried using wildcard certs with LDAP, nor using SubjectAlternativeName field,
but I have feeling that not all clients are capable of using it.

Setting TLS_REQCERT to never is only good for debugging, I discourage using it even for testing
since You could end up with insecure installation. For production use TLS_REQCERT should be set to demand,
otherwise there is no point in using certs - there is always MITM attack possibility (that is especially true, if
password in clear text flows thru LDAP connections, which happens often when user changes his password).

Matej Zagiba


It works. Thank you everybody.
I don't understand everything, especially the fact that gnutls-cli work so I'll
try to reinstall all, and see if I'll find the same error.