Syncrepl SSL fail

[Hugo Deprez]

Dear community,

I setup a syncrepl between my master openldap server and a consumer.

I am trying to use SSL for this syncrepl
I got the following error in the log when I start slapd on the consumer :

Oct 13 17:04:59 server slapd[16905]: slapd starting
Oct 13 17:04:59 server slapd[16905]: slap_client_connect:
URI=ldaps://ldap.mydomain.fr:1024/
DN="cn=syncrepluser,o=others,dc=mydomain,dc=fr" ldap_sasl_bind_s
failed (-1)
Oct 13 17:04:59 server slapd[16905]: do_syncrepl: rid=003 rc -1
retrying (9 retries left)


I don't understand why it is failing as a single ldapsearch from the
same server with the syncrepl user is working.

here is my syncrepl configuration :

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
binddn="cn=syncrepluser,o=others,dc=mydomain,dc=fr"
credentials=my_password


Any idea ?

Regards,

Hugo

[Chris Jacobs]

What is your ldapsearch command?

- chris

-----Original Message-----
From: openldap-technical-***@OpenLDAP.org [mailto:openldap-technical-***@OpenLDAP.org] On Behalf Of Hugo Deprez
Sent: Thursday, October 13, 2011 9:39 AM
To: openldap-***@openldap.org
Subject: Syncrepl SSL fail

Dear community,

I setup a syncrepl between my master openldap server and a consumer.

I am trying to use SSL for this syncrepl
I got the following error in the log when I start slapd on the consumer :

Oct 13 17:04:59 server slapd[16905]: slapd starting
Oct 13 17:04:59 server slapd[16905]: slap_client_connect:
URI=ldaps://ldap.mydomain.fr:1024/
DN="cn=syncrepluser,o=others,dc=mydomain,dc=fr" ldap_sasl_bind_s
failed (-1)
Oct 13 17:04:59 server slapd[16905]: do_syncrepl: rid=003 rc -1
retrying (9 retries left)


I don't understand why it is failing as a single ldapsearch from the
same server with the syncrepl user is working.

here is my syncrepl configuration :

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
binddn="cn=syncrepluser,o=others,dc=mydomain,dc=fr"
credentials=my_password


Any idea ?

Regards,

Hugo



This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system.

[Quanah Gibson-Mount]

--On Thursday, October 13, 2011 6:38 PM +0200 Hugo Deprez

Post by Hugo Deprez
Dear community,
I setup a syncrepl between my master openldap server and a consumer.
I am trying to use SSL for this syncrepl
Oct 13 17:04:59 server slapd[16905]: slapd starting
URI=ldaps://ldap.mydomain.fr:1024/
DN="cn=syncrepluser,o=others,dc=mydomain,dc=fr" ldap_sasl_bind_s
failed (-1)
Oct 13 17:04:59 server slapd[16905]: do_syncrepl: rid=003 rc -1
retrying (9 retries left)
I don't understand why it is failing as a single ldapsearch from the
same server with the syncrepl user is working.
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
binddn="cn=syncrepluser,o=others,dc=mydomain,dc=fr"
credentials=my_password
Any idea ?

I don't see any of the tls_* options to the syncrepl configuration here.
Likely the syncrepl client is unable to verify the master's cert. I would
note that using refreshOnly is ill-advised.

--Quanah



--

Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration

[Josh Miller]

I don't see any of the tls_* options to the syncrepl configuration here. Likely the syncrepl client is unable to verify the master's cert. I would note that using refreshOnly is ill-advised.

Hi Quanah,

Why is RefreshOnly ill-advised? That is the recommendation in the docs (very timely as I just set this up again myself).

re: http://www.openldap.org/doc/admin24/replication.html

Thanks!

Josh Miller
Open Source Solutions Architect
[phone]
http://itsecureadmin.com/

[Quanah Gibson-Mount]

--On October 13, 2011 10:43:55 AM -0700 Josh Miller

Post by Josh Miller

Post by Quanah Gibson-Mount
I don't see any of the tls_* options to the syncrepl configuration here.
Likely the syncrepl client is unable to verify the master's cert. I
would note that using refreshOnly is ill-advised.

Hi Quanah,
Why is RefreshOnly ill-advised? That is the recommendation in the docs
(very timely as I just set this up again myself).
re: http://www.openldap.org/doc/admin24/replication.html

The admin guide has examples, not recommendations. In any case, I fully
intend to change those examples to be refreshAndPersist so people stop
defaulting to refreshOnly. It is not always reliable, and your
significantly delay your replication by using it.

--Quanah

[Howard Chu]

Post by Quanah Gibson-Mount
--On October 13, 2011 10:43:55 AM -0700 Josh Miller

Post by Josh Miller

Post by Quanah Gibson-Mount
I don't see any of the tls_* options to the syncrepl configuration here.
Likely the syncrepl client is unable to verify the master's cert. I
would note that using refreshOnly is ill-advised.

Hi Quanah,
Why is RefreshOnly ill-advised? That is the recommendation in the docs
(very timely as I just set this up again myself).
re: http://www.openldap.org/doc/admin24/replication.html

The admin guide has examples, not recommendations. In any case, I fully
intend to change those examples to be refreshAndPersist so people stop
defaulting to refreshOnly. It is not always reliable, and your
significantly delay your replication by using it.

Of course, it may be the only thing that works reliably if you have a firewall
that silently kills old connections.

The examples should stand as-is. We cannot predict what environment it's going
to be deployed in. It's up to administrators to use their brains and know
these details of their network.

[Hugo Deprez]

Hello,

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 ?

Thanks for you help.

Regards,

Hugo

Post by Howard Chu

Post by Quanah Gibson-Mount
--On October 13, 2011 10:43:55 AM -0700 Josh Miller

Post by Josh Miller

Post by Quanah Gibson-Mount
I don't see any of the tls_* options to the syncrepl configuration here.
Likely the syncrepl client is unable to verify the master's cert.  I
would note that using refreshOnly is ill-advised.

Hi Quanah,
Why is RefreshOnly ill-advised?  That is the recommendation in the docs
(very timely as I just set this up again myself).
re:  http://www.openldap.org/doc/admin24/replication.html

The admin guide has examples, not recommendations.  In any case, I fully
intend to change those examples to be refreshAndPersist so people stop
defaulting to refreshOnly.  It is not always reliable, and your
significantly delay your replication by using it.

Of course, it may be the only thing that works reliably if you have a
firewall that silently kills old connections.
The examples should stand as-is. We cannot predict what environment it's
going to be deployed in. It's up to administrators to use their brains and
know these details of their network.
--
 -- Howard Chu
 CTO, Symas Corp.           http://www.symas.com
 Director, Highland Sun     http://highlandsun.com/hyc/
 Chief Architect, OpenLDAP  http://www.openldap.org/project/

[Philip Guenther]

Post by Hugo Deprez
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

[Michael Ströder]

Post by Philip Guenther
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.

Glad someone else is also trying to avoid the use of such fuzzy terms in this
context.

http://www.openldap.org/faq/data/cache/605.html

Ciao, Michael.

[Howard Chu]

Post by Philip Guenther
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.)

Frankly I agree with you that the original behavior was better. As far as I
recall, though i don't believe it was never documented anywhere, the main
point to using ALLOW was to accept certs that were expired but otherwise
correct. The current patch in git makes you totally defenseless against MITM
attacks, and I can't see any reason why it would ever be correct to deploy
this way.

[Hugo Deprez]

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

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]

Post by Hugo Deprez
Hello Philip,
thank you for your explanation.
This is more clear now.
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.

Post by Hugo Deprez
Regards,
On 18 October 2011 06:28, Philip Guenther

Post by Philip Guenther

Post by Hugo Deprez
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

[Hugo Deprez]

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,

Post by Raffael Sahli

Post by Hugo Deprez
Hello Philip,
thank you for your explanation.
This is more clear now.
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.

Post by Hugo Deprez
Regards,
On 18 October 2011 06:28, Philip Guenther

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
Switzerland

[Hugo Deprez]

Hello,

after reading :
https://bugzilla.redhat.com/show_bug.cgi?format=multiple&id=734187

It seems that when the consumer provide ldaps service, I must specify
tls_key and tls_cert parameter with the provider files.

If not specified, syncrepl will use consumer certificat and they will
never match the provider cert. This is why I got the error :
slapd[31043]: do_syncrepl: rid=003 rc -1 retrying (9 retries left)
the private key didn't match with the provider.

So in this setup, cert and private key from provider must be deployed
on each consumer.

Regards,

Hugo

Post by Hugo Deprez
Hello,
 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,

Post by Raffael Sahli

Post by Hugo Deprez
Hello Philip,
thank you for your explanation.
This is more clear now.
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.

Post by Hugo Deprez
Regards,
On 18 October 2011 06:28, Philip Guenther

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
Switzerland

[Quanah Gibson-Mount]

Post by Howard Chu

Post by Quanah Gibson-Mount
--On October 13, 2011 10:43:55 AM -0700 Josh Miller

Post by Josh Miller

Post by Quanah Gibson-Mount
I don't see any of the tls_* options to the syncrepl configuration
here. Likely the syncrepl client is unable to verify the master's
cert. I would note that using refreshOnly is ill-advised.

Hi Quanah,
Why is RefreshOnly ill-advised? That is the recommendation in the docs
(very timely as I just set this up again myself).
re: http://www.openldap.org/doc/admin24/replication.html

The admin guide has examples, not recommendations. In any case, I fully
intend to change those examples to be refreshAndPersist so people stop
defaulting to refreshOnly. It is not always reliable, and your
significantly delay your replication by using it.

Of course, it may be the only thing that works reliably if you have a
firewall that silently kills old connections.
The examples should stand as-is. We cannot predict what environment it's
going to be deployed in. It's up to administrators to use their brains
and know these details of their network.

I think at the least we should document both. Virtually everyone takes the
admin guide verbatim without comprehending what it is they are doing.
Giving them two options would hopefully at least make them have to consider
why there are multiple options.

--Quanah

--

Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration

[Hugo Deprez]

Hello,

tls_reqcert=never is necessary for the replication. If it is not
defined, I get an error.

The weird thing, is that I do have the same configuration on another
host, running Debian Lenny with slapd version 2.4.23-3 and I don't
have to define this parameter.

The server I report the error, is running 2.4.23-7 on Squeeze.

Is there any way to explain this difference ?

Regards,

Hugo

Post by Howard Chu

Post by Quanah Gibson-Mount
--On October 13, 2011 10:43:55 AM -0700 Josh Miller

Post by Josh Miller

Post by Quanah Gibson-Mount
I don't see any of the tls_* options to the syncrepl configuration
here. Likely the syncrepl client is unable to verify the master's
cert.  I would note that using refreshOnly is ill-advised.

Hi Quanah,
Why is RefreshOnly ill-advised?  That is the recommendation in the docs
(very timely as I just set this up again myself).
re:  http://www.openldap.org/doc/admin24/replication.html

The admin guide has examples, not recommendations.  In any case, I fully
intend to change those examples to be refreshAndPersist so people stop
defaulting to refreshOnly.  It is not always reliable, and your
significantly delay your replication by using it.

Of course, it may be the only thing that works reliably if you have a
firewall that silently kills old connections.
The examples should stand as-is. We cannot predict what environment it's
going to be deployed in. It's up to administrators to use their brains
and know these details of their network.

I think at the least we should document both.  Virtually everyone takes the
admin guide verbatim without comprehending what it is they are doing. Giving
them two options would hopefully at least make them have to consider why
there are multiple options.
--Quanah
--
Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
--------------------
Zimbra ::  the leader in open source messaging and collaboration

[Hugo Deprez]

Hello,

I use the following ldapsearch command :


ldapsearch -H ldaps://ldap.mydomain.fr:1024 -x -W -D
"cn=syncrepluser,o=others,dc=mydomain,dc=fr"

I did configure TLS cert file before syncrepl configuration :

TLSCACertificateFile /etc/ssl/certs/ldap-replic-cert.pem
TLSCertificateFile /etc/ssl/certs/ldap-replic-cert.pem
TLSCertificateKeyFile /etc/ssl/certs/ldap-replic-cert.pem

But those certificate are for the ldap consumer if I'm not wrong.

I am currently trying the following configuration thanks to your information :


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_cert=/etc/ssl/certs/ldap-cert.pem
tls_cacert=/etc/ssl/certs/ldap-cert-ca.pem
binddn="cn=syncrepluser,o=others,dc=mydomain,dc=fr"
credentials=my_password

where tls_cert and tls_cacert provide the cert from the master server.

It seems that the replication is working but I get an other error confusing :

ct 14 12:46:53 server slapd[32470]: slap_client_connect:
URI=ldaps://ldap.mydomain.fr:1024/ TLS context initialization failed
(-1)
Oct 14 12:46:53 server slapd[32470]: do_syncrepl: rid=003 rc -1
retrying (9 retries left)
Oct 14 12:47:53 server slapd[32470]: do_syncrep2: rid=003
LDAP_RES_INTERMEDIATE - SYNC_ID_SET
Oct 14 12:47:53 server slapd[32470]: do_syncrep2: rid=003
LDAP_RES_INTERMEDIATE - SYNC_ID_SET
Oct 14 12:47:53 server slapd[32470]: do_syncrep2: rid=003
LDAP_RES_INTERMEDIATE - SYNC_ID_SET


I don't really understand the TLS context initialization failed (-1)
as my replication is working ?

Thanks for the tips.

Hugo

Post by Quanah Gibson-Mount
--On Thursday, October 13, 2011 6:38 PM +0200 Hugo Deprez

Post by Hugo Deprez
Dear community,
I setup a syncrepl between my master openldap server and a consumer.
I am trying to use SSL for this syncrepl
Oct 13 17:04:59 server slapd[16905]: slapd starting
URI=ldaps://ldap.mydomain.fr:1024/
DN="cn=syncrepluser,o=others,dc=mydomain,dc=fr" ldap_sasl_bind_s
failed (-1)
Oct 13 17:04:59 server slapd[16905]: do_syncrepl: rid=003 rc -1
retrying (9 retries left)
I don't understand why it is failing as a single ldapsearch from the
same server with the syncrepl user is working.
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
              binddn="cn=syncrepluser,o=others,dc=mydomain,dc=fr"
              credentials=my_password
Any idea ?

I don't see any of the tls_* options to the syncrepl configuration here.
Likely the syncrepl client is unable to verify the master's cert.  I would
note that using refreshOnly is ill-advised.
--Quanah
--
Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
--------------------
Zimbra ::  the leader in open source messaging and collaboration

[Hugo Deprez]

Hello,

On the provider I have the following settings :

TLSCACertificateFile /etc/ssl/certs/ldap-cert.pem
TLSCertificateFile /etc/ssl/certs/ldap-cert.pem
TLSCertificateKeyFile /etc/ldap/ssl/ldap-key.pem

but no TLSCipherSuite defined.

I added the starttls=yes on the consumer :

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
starttls=yes
tls_cert=/etc/ssl/certs/ldap-cert.pem
tls_cacert=/etc/ssl/certs/ldap-cert-ca.pem
binddn="cn=syncrepluser,o=others,dc=mydomain,dc=fr"
credentials=my_password


But still the same error.

Any idea ?

Hugo

Post by Hugo Deprez
Hi,
TLSCertificateFile
TLSCertificateKeyFile
TLSCipherSuite
On the provider ?
You probably also want to set this up correctly in
 starttls=yes
 tls_cacert=/path/to/certificate
I suspect better if TLS_CACERT is also properly
set up in both ldap server slapd config.
---
Olivier

Post by Hugo Deprez
Dear community,
I setup a syncrepl between my master openldap server and a consumer.
I am trying to use SSL for this syncrepl
Oct 13 17:04:59 server slapd[16905]: slapd starting
URI=ldaps://ldap.mydomain.fr:1024/
DN="cn=syncrepluser,o=others,dc=mydomain,dc=fr" ldap_sasl_bind_s
failed (-1)
Oct 13 17:04:59 server slapd[16905]: do_syncrepl: rid=003 rc -1
retrying (9 retries left)
I don't understand why it is failing as a single ldapsearch from the
same server with the syncrepl user is working.
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
              binddn="cn=syncrepluser,o=others,dc=mydomain,dc=fr"
              credentials=my_password
Any idea ?
Regards,
Hugo

[Nick Milas]

Post by Hugo Deprez
I don't understand why it is failing as a single ldapsearch from the
same server with the syncrepl user is working.

I had exactly the same problem.

Following directions from:
http://blaoism.blogspot.com/2010/05/ldapsaslbinds-failed.html, I added
tls_reqcert=never to syncrepl directives on the consumer, and this
solved the problem.

You may want to see my case here: http://tools.lsc-project.org/issues/328

Here is my setup on the consumer:

# Consumer Sync
syncrepl rid=333
provider=ldaps://ldap.example.com
tls_reqcert=never
type=refreshAndPersist
retry="60 +"
searchbase="dc=example,dc=com"
schemachecking=off
bindmethod=simple
binddn="uid=dnsauthusr,ou=System,dc=example,dc=com"
credentials="mypassword"

I hope that helps.

Nick

[Nick Milas]

tls_reqcert=demand
and add starttls=critical

In my installations, syncrepl doesn't work with these directives
(although ldapsearch using ldaps: works fine).

I wonder what may be the cause...

Nick

[Quanah Gibson-Mount]

Post by Nick Milas

tls_reqcert=demand
and add starttls=critical

In my installations, syncrepl doesn't work with these directives
(although ldapsearch using ldaps: works fine).

startTLS and ldaps are two entirely different mechanisms, and do not work
together. I.e., you cannot do startTLS to an ldaps:// URI.

--Quanah

[Rich Megginson]

Post by Hugo Deprez
Hello,
TLSCACertificateFile /etc/ssl/certs/ldap-cert.pem
TLSCertificateFile /etc/ssl/certs/ldap-cert.pem
TLSCertificateKeyFile /etc/ldap/ssl/ldap-key.pem
but no TLSCipherSuite defined.

That should be fine. You don't need to define a TLSCipherSuite

Post by Hugo Deprez
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
starttls=yes

You should have starttls=critical or it will attempt to fallback to
plain LDAP if it cannot establish TLS.

Post by Hugo Deprez
tls_cert=/etc/ssl/certs/ldap-cert.pem

You should not have tls_cert here, since you are trying to use
dn/password auth. tls_cert is useless without tls_key anyway.

Post by Hugo Deprez
tls_cacert=/etc/ssl/certs/ldap-cert-ca.pem
binddn="cn=syncrepluser,o=others,dc=mydomain,dc=fr"
credentials=my_password
But still the same error.
Any idea ?
Hugo

Post by Hugo Deprez
Hi,
TLSCertificateFile
TLSCertificateKeyFile
TLSCipherSuite
On the provider ?
You probably also want to set this up correctly in
starttls=yes
tls_cacert=/path/to/certificate
I suspect better if TLS_CACERT is also properly
set up in both ldap server slapd config.
---
Olivier

Post by Hugo Deprez
Dear community,
I setup a syncrepl between my master openldap server and a consumer.
I am trying to use SSL for this syncrepl
Oct 13 17:04:59 server slapd[16905]: slapd starting
URI=ldaps://ldap.mydomain.fr:1024/
DN="cn=syncrepluser,o=others,dc=mydomain,dc=fr" ldap_sasl_bind_s
failed (-1)
Oct 13 17:04:59 server slapd[16905]: do_syncrepl: rid=003 rc -1
retrying (9 retries left)
I don't understand why it is failing as a single ldapsearch from the
same server with the syncrepl user is working.
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
binddn="cn=syncrepluser,o=others,dc=mydomain,dc=fr"
credentials=my_password
Any idea ?
Regards,
Hugo