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.

--On October 13, 2011 10:43:55 AM -0700 Josh Miller <joshua(a)itsecureadmin.com&gt; wrote: > > On Oct 13, 2011, at 10:29 AM, Quanah Gibson-Mount wrote: >> >> 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.

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 ?

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.)

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(a)sendmail.com&gt; 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

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(a)raffaelsahli.com&gt; 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(a)sendmail.com&gt;  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(a)raffaelsahli.com > Switzerland >