[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Syncrepl SSL fail
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 <public@raffaelsahli.com> 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
>> <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
>
>
>
> --
> Raffael Sahli
> public@raffaelsahli.com
> Switzerland
>