Re: Syncrepl SSL fail

[Hugo Deprez <hugo.deprez@gmail.com>]

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 ?

Regards,





On 18 October 2011 06:28, Philip Guenther
<guenther+ldaptech@sendmail.com> 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