Hello, if I don't sepcify the key path I get the following error when starting slpad :
slap_client_connect: URI=ldaps://ldap.domain.fr:1024/ TLS context initialization failed (-1) slapd[31043]: do_syncrepl: rid=003 rc -1 retrying (9 retries left) So I need the tls_key=/etc/ldap/ssl/ldap-key.pem pointing to the key of the provider. Any idea why I should specify the private key of the provider ? Regards, On 2 December 2011 15:11, Raffael Sahli <[email protected]> wrote: > On 12/02/2011 02:50 PM, Hugo Deprez wrote: >> >> Hello Philip, >> >> thank you for your explanation. >> >> This is more clear now. >> >> So I changed my configuration like : >> >> Syncrepl rid=003 >> provider=ldaps://my.server:1024/ >> type=refreshOnly >> retry="60 10 600 +" >> interval=00:00:00:10 >> searchbase="dc=my,dc=domain" >> scope=sub >> schemachecking=on >> bindmethod=simple >> tls_reqcert=demand >> tls_cert=/etc/ssl/certs/ldap-cert.pem >> tls_cacert=/etc/ssl/certs/ldap-cert.pem >> tls_key=/etc/ldap/ssl/ldap-key.pem >> binddn="cn=syncrepluser..." >> credentials=******** >> >> I added the tls_key, tls_cacert, tls_reqcert parameter. >> The tls option are using the certificate and the key of the LDAP Provider. >> >> The last thing I don't understand is that the tls_key is needed. So I >> need to deploy the private key of the provider to each consumer. >> >> I though the certificate would be sufficient ? > > > No you don't have to deploy the private key! > In syncrepl, just define the tls_cacert, and it works. > > > >> >> Regards, >> >> >> >> >> >> On 18 October 2011 06:28, Philip Guenther >> <[email protected]> wrote: >>> >>> On Sun, 16 Oct 2011, Hugo Deprez wrote: >>>> >>>> It seems that the proper configuration for my case is : >>>> >>>> syncrepl rid=003 >>>> provider=ldaps://ldap.mydomain.fr:1024/ >>>> type=refreshOnly >>>> retry="60 10 600 +" >>>> interval=00:00:00:10 >>>> searchbase="dc=mydomain,dc=fr" >>>> scope=sub >>>> schemachecking=on >>>> bindmethod=simple >>>> tls_reqcert=never >>>> binddn="cn=syncrepluser,o=others,dc=mydomain,dc=fr" >>>> credentials=my_password >>>> >>>> It works, but I am confuse with those parameters. If I understand >>>> well, I will never use TLS here, but only ssl ? >>>> Hence, it was a TLS issue ? >>> >>> No, you're using TLS. You're just not using the StartTLS operation. >>> >>> There are two ways to use SSL/TLS: "negotiate-on-connect" and "upgrade >>> from clear". The former is what you get when you use an ldaps:// URL, >>> where the first data the client sends is the raw SSL/TLS ClientHello >>> packet. The latter is what you get when you use an ldap:// URL and have >>> starttls=yes or starttls=critical, where the first data the client sends >>> is LDAP protocol data in the clear, including a StartTLS request. If the >>> server sends a success response to that StartTLS request, then the client >>> starts the SSL/TLS handshake with its ClientHello packet. >>> >>> This should answer why it failed when you tried to combine an ldaps:// >>> URL >>> with starttls=yes: the exchange was already using SSL/TLS and (rightly) >>> libldap won't let you negotiate multiple levels of SSL/TLS encryption. >>> >>> (You may note that I write "SSL/TLS". That's because they're just >>> different versions of the same protocol. Using 'SSL' as a shorthand for >>> "negotiate on connect" and 'TLS' for "upgrade from clear" is poor naming, >>> as the choice of method is orthogonal to the protocol version. Your >>> ldaps:// connection is probably negotiating the TLS 1.0 protocol (aka SSL >>> version 3.1), just as an ldap:// connection using StartTLS may, on a >>> poorly configured server, negotiate SSL 3.0) >>> >>> >>> Next: the fact that you need tls_reqcert=never for TLS negotiation to >>> succeed strongly suggests the problem is either >>> a) the subject and subjectAltName of the cert don't match the hostname in >>> the URL, OR >>> b) the client doesn't have the self-signed CA cert at the root of the >>> signing chain for the server's cert. >>> >>> Those are both necessary to protect the server against Man-in-the-Middle >>> attacks. >>> >>> (It used to be that tls_reqcert=allow would disable check (b) and only >>> perform check (a), or at least that was the case when using the OpenSSL >>> crypto backend, but that behavior has apparently been removed from the >>> version in git as of August. Given the vagaries of the error reporting >>> of >>> the underlying crypto libraries, this was a useful tool in tracking down >>> which check was causing TLS failures. Oh well.) >>> >>> So, does the server's certificate subject or subjectAltName match the >>> hostname from the URL the client is using? Have you verified that the CA >>> at the root of the server's cert's chain really is configured for the >>> client? >>> >>> >>> Philip Guenther > > > > -- > Raffael Sahli > [email protected] > Switzerland >
