Re: Syncrepl SSL fail

[Philip Guenther <guenther+ldaptech@sendmail.com>]

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