On 12/02/2011 02:50 PM, Hugo Deprez wrote:
thank you for your explanation.
This is more clear now.
So I changed my configuration like :
retry="60 10 600 +"
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.
On 18 October 2011 06:28, Philip Guenther
> On Sun, 16 Oct 2011, Hugo Deprez wrote:
>> It seems that the proper configuration for my case is :
>> syncrepl rid=003
>> retry="60 10 600 +"
>> 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
> 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
> (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
> Philip Guenther