--On December 20, 2007 11:03:44 AM -0500 "Chris G. Sellers" <chris.sellers(a)nitle.org&gt; wrote: > which suggests that the connection could not be made on port 389 via TLS. > I can't figure out how to tell the repl connection to send a certificate. > Do I have to setup a user in LDAP with a cert? Do I put a client cert > into the syncrepl section of the slapd.conf file on the slave? Please > advise. You are confused. LDAPv3 startTLS is used to encrypt connections over port 389 (or other ports). The Ldapv2 HACK to do TLS over port 636 (ldaps://) is the other way of doing SSL encryption. You are mixing these two very different mechanisms. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

I think I see what you are saying. The ldaps: is forcing the implied SSL not startTLS. Thanks for making me think different. so now I just need to switch back to ldap:// and make sure TLS is setup and sniff to make sure the traffic is encrypted. Thanks Sellers On Dec 20, 2007, at 11:54 AM, Quanah Gibson-Mount wrote: > > > --On December 20, 2007 11:03:44 AM -0500 "Chris G. Sellers" > <chris.sellers(a)nitle.org&gt; wrote: > > which suggests that the connection could not be made on port 389 > via TLS. > > I can't figure out how to tell the repl connection to send a > certificate. > > Do I have to setup a user in LDAP with a cert? Do I put a client > cert > > into the syncrepl section of the slapd.conf file on the slave? > Please > > advise. > > You are confused. LDAPv3 startTLS is used to encrypt connections > over port > 389 (or other ports). The Ldapv2 HACK to do TLS over port 636 > (ldaps://) > is the other way of doing SSL encryption. You are mixing these > two very > different mechanisms. > > --Quanah > > > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration > ______________________________________________ Chris G. Sellers | NITLE Technology 734.661.2318 | chris.sellers(a)nitle.org AIM: imthewherd | GTalk: cgseller(a)gmail.com

Did you add the startTLS directive to your syncrepl configuration? --Quanah --On December 20, 2007 2:02:05 PM -0500 "Chris G. Sellers" <chris.sellers(a)nitle.org&gt; wrote: > No - I didn't understand you correctly. I switched back to ldap://:389 > and sniffed and it was all there in the clear. > > > I need to encrypt the communication (and binding) of the replication from > the Master to the Slave. I can not seem to get it to work and I can't > find the documentation where it shows how to set the replication for the > syncrepl to be SSL or TLS. > > > Sellers > > > > On Dec 20, 2007, at 1:22 PM, Chris G. Sellers wrote: > > > I think I see what you are saying. The ldaps: is forcing the implied > SSL not startTLS. Thanks for making me think different. > > > so now I just need to switch back to ldap:// and make sure TLS is setup > and sniff to make sure the traffic is encrypted. > > > Thanks > > > Sellers > > > > On Dec 20, 2007, at 11:54 AM, Quanah Gibson-Mount wrote: > > > > > > --On December 20, 2007 11:03:44 AM -0500 "Chris G. Sellers" > <chris.sellers(a)nitle.org&gt; wrote: > > which suggests that the connection could not be made on port 389 via > TLS. > > I can't figure out how to tell the repl connection to send a > certificate. > > Do I have to setup a user in LDAP with a cert? Do I put a client cert > > into the syncrepl section of the slapd.conf file on the slave? Please > > advise. > > You are confused. LDAPv3 startTLS is used to encrypt connections over port > 389 (or other ports). The Ldapv2 HACK to do TLS over port 636 (ldaps://) > is the other way of doing SSL encryption. You are mixing these two very > different mechanisms. > > --Quanah > > > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration > > > > > > > ______________________________________________ > Chris G. Sellers | NITLE Technology > 734.661.2318 | chris.sellers(a)nitle.org > AIM: imthewherd | GTalk: cgseller(a)gmail.com > > > > > > ______________________________________________ > Chris G. Sellers | NITLE Technology > 734.661.2318 | chris.sellers(a)nitle.org > AIM: imthewherd | GTalk: cgseller(a)gmail.com -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

Hello! On Thu, 20 Dec 2007 11:03:44 -0500 "Chris G. Sellers" <chris.sellers(a)nitle.org&gt; wrote: > I have setup sync replication on two OpenLDAP servers. I have it > successfully working via ldap://:389 > > I then setup TLS for SSL connections. I used a self signed cert > (using the OpenLDAP how-to) as well as a CAsigned cert from > cacert.org. I've setup the ca.crt in the ldap.conf file on both > the master and slave. I've also setup the ca.cert in the TLS for > the master server that the sync repl host connects to. > > I've tested the cert with a connection via ldap -Z and -d debug > option and seen that the cert appears to be validated. > > So, when I turn on ldaps:// for the syncrepl section of the slave > server, and use port 389 I get a bind error

> which suggests that the connection could not be made on port 389 via > TLS. I can't figure out how to tell the repl connection to send a > certificate. Do I have to setup a user in LDAP with a cert? Do I > put a client cert into the syncrepl section of the slapd.conf file > on the slave? Please advise.

Indeed, I have also found that in the OpenLDAP documentation there are no directions about what kind of cert should be used for a syncrepl consumer, nor about how they could be specified - one may guess that one has to use the tls-related suboptions of the syncrepl option but there are no directions, no examples, no nothing. And then it does not work in the first place and does not have usable log or even debug output either...

When I set up normal SSL with provider="ldaps://<host>:636" then I simply get the same error you're getting and even with debug mode I could not get any details about the TLS/SSL handshake or what exactly the problem is.

IMHO it is extremely harsh how the self-signed certs are treated by OpenLDAP. In the majority of cases this is forcing people (after many hours of struggling) to use "TLS_REQCERT never" or similar settings, which ends up being a lot more insecure than it would be to accept a known self-signed cert... Not to mention that the syncrepl suboption "tls_reqcert=never" is apparently ignored so practically I've found that syncrepl is currently inoperable with any form of encryption. Is there anybody who could tell me what this is good for?

I'm using certificates I've generated since many years with a lot of software having SSL support like Apache, Cyrus IMAP, Postfix, OpenVPN, etc. and all of these are working seamlessly, with the exception of OpenLDAP. It's not only me who's struggling, just Google around if you don't believe me... Even the Gentoo Linux ebuild for OpenLDAP suggests that I have to use "TLS_REQCERT never" with self-signed certificates or else TLS won't work. And they're right.

To a proper self-signed certificate OpenLDAP simply says "self-signed certificate in certificate chain" or something like that and TLS/SSL handshake fails with an error.

Hello! On Thu, 20 Dec 2007 12:08:16 -0800 Quanah Gibson-Mount <quanah(a)zimbra.com&gt; wrote: > > IMHO it is extremely harsh how the self-signed certs are treated by > > OpenLDAP. In the majority of cases this is forcing people (after > > many hours of struggling) to use "TLS_REQCERT never" or similar > > settings, which ends up being a lot more insecure than it would be > > to accept a known self-signed cert... Not to mention that the > > syncrepl suboption "tls_reqcert=never" is apparently ignored so > > practically I've found that syncrepl is currently inoperable with > > any form of encryption. Is there anybody who could tell me what > > this is good for? > > Interestingly, plenty of people have gotten this to work. First, you > need to know how to create self-signed certs using a CA. Of course, > that's really off-topic for the OpenLDAP list, even though it has > been discussed many times. But until you know how to get that > working, you won't be able to get the syncrepl client to work, either. I'm using certificates I've generated since many years with a lot of software having SSL support like Apache, Cyrus IMAP, Postfix, OpenVPN, etc. and all of these are working seamlessly, with the exception of OpenLDAP.

It's not only me who's struggling, just Google around if you don't believe me... Even the Gentoo Linux ebuild for OpenLDAP suggests that I have to use "TLS_REQCERT never" with self-signed certificates or else TLS won't work. And they're right.

To a proper self-signed certificate OpenLDAP simply says "self-signed certificate in certificate chain" or something like that and TLS/SSL handshake fails with an error.

Hello! On Thu, 20 Dec 2007 16:34:03 -0800 Quanah Gibson-Mount <quanah(a)zimbra.com&gt; wrote:

TLSCACertificateFile /etc/ssl/certs/CA.pem TLSCertificateFile /etc/openldap/ssl/ldap-server.crt TLSCertificateKeyFile /etc/openldap/ssl/ldap-server.key And at the clients:

tls_cacertfile /etc/ssl/certs/CA.pem #tls_cacertdir /etc/ssl/certs tls_cert /etc/openldap/ssl/ldap-client.crt tls_key /etc/openldap/ssl/ldap-client.key

--On December 21, 2007 11:22:10 AM +0100 RUMI Szabolcs <rumi_ml(a)rtfm.hu&gt; wrote: > And at the clients: > > tls_cacertfile /etc/ssl/certs/CA.pem ># tls_cacertdir /etc/ssl/certs > tls_cert /etc/openldap/ssl/ldap-client.crt > tls_key /etc/openldap/ssl/ldap-client.key > > Is this wrong? I've run into issues on some platforms, where I had to use the TLS_CACERTDIR directive in slapd.conf