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@nitle.org 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@nitle.org AIM: imthewherd | GTalk: cgseller@gmail.com

______________________________________________ Chris G. Sellers | NITLE Technology 734.661.2318 | chris.sellers@nitle.org AIM: imthewherd | GTalk: cgseller@gmail.com

I did not, as I didn't see it in the specification (although I didn't read the source code or the man page for slapd.conf) If I look at the man page I see there is an option starttls=yes. I tried that on the slave and sniffed, and VIOLA, I can see the TLS do the handshake for the certificate.

If someone can update the Admin guide to include the starttls option that would be cool . Below is what is posted in the admin23 doc and the man page from 2.3.xx is below that. (I remember now why I love MAN pages) Thanks Quanah.

syncrepl rid=<replica ID> provider=ldap[s]://<hostname>[:port] [type=refreshOnly|refreshAndPersist] [interval=dd:hh:mm:ss] [retry=[<retry interval> <# of retries>]+] [searchbase=<base DN>] [filter=<filter str>] [scope=sub|one|base] [attrs=<attr list>] [attrsonly] [sizelimit=<limit>] [timelimit=<limit>] [schemachecking=on|off] [bindmethod=simple|sasl] [binddn=<DN>] [saslmech=<mech>] [authcid=<identity>] [authzid=<identity>] [credentials=<passwd>] [realm=<realm>] [secprops=<properties>]

syncrepl rid=<replica ID> provider=ldap[s]://<hostname>[:port] [type=refreshOnly|refreshAndPersist] [interval=dd:hh:mm:ss] [retry=[<retry interval> <# of retries>]+] searchbase=<base DN> [filter=<filter str>] [scope=sub|one|base] [attrs=<attr list>] [attrsonly] [sizelimit=<limit>] [timelimit=<limit>] [schemachecking=on|off] [starttls=yes|critical] [bindmethod=simple| sasl] [binddn=<dn>] [saslmech=<mech>] [authcid=<identity>] [authzid=<identity>] [credentials=<passwd>] [realm=<realm>] [secprops=<properties>] [logbase=<base DN>] [logfilter=<filter str>] [syncdata=default|accesslog|changelog]

On Dec 20, 2007, at 2:09 PM, Quanah Gibson-Mount wrote:

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@nitle.org 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@nitle.org 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@nitle.org AIM: imthewherd | GTalk: cgseller@gmail.com

---

Chris G. Sellers | NITLE Technology 734.661.2318 | chris.sellers@nitle.org AIM: imthewherd | GTalk: cgseller@gmail.com

--

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@nitle.org AIM: imthewherd | GTalk: cgseller@gmail.com

--On December 20, 2007 7:45:13 PM +0100 RUMI Szabolcs rumi_ml@rtfm.hu 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.

--Quanah

--

Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

RUMI Szabolcs wrote:

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.

No, they're wrong. Likewise, most of the other software you've had "working seamlessly" is broken but most people were too ignorant of best practices to realize it. Now that malware is so common on the web, newer browsers like Firefox/Mozilla are finally tightening their own validity checks on certificates as well, and refusing to connect to sites with unrecognized certs. I.e., they're finally beginning to do what they were supposed to do all along, and what OpenLDAP has always done.

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.

The OpenLDAP documentation tells you how to properly configure certificates. Ignore it and you get errors. Follow it and it works securely.

Hello!

On Thu, 20 Dec 2007 16:34:03 -0800 Quanah Gibson-Mount quanah@zimbra.com wrote:

Just to note, we use self-signed certs @ Zimbra with OpenLDAP, we force TLS, and it works without a problem. Which is why I know you're incorrect. ;) And I'd hardly look to the gentoo folks as a source of documentation expertise when it comes to OpenLDAP.

OK, then something must be different between our setups...

What I'm doing is that I've generated an X509 self-signed CA certificate and I'm signing all server and client certificates with that CA cert. This CA cert is distributed to all clients' /etc/ssl/certs directory and this way the software packages using openssl usually recognize it and clients are able to validate the server certs and vica versa.

Now this doesn't work with OpenLDAP. It also doesn't work when I set up the CA cert file explicitly instead of just copying it to /etc/ssl/certs like this:

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

Is this wrong?

I'm not saying I'm an SSL expert, I'm certainly not, nor do I think that the Gentoo people are too much of an expert in terms of OpenLDAP or SSL. I can only tell what my experience shows and the Gentoo people are probably also base their HOWTOs and stuff on their real-world experiences which is probably the reason why their advices are sometimes rather "unscientific". IMHO people are trying to solve problems in an "unscientific" way when the "scientific" way does not work, is too complicated, is poorly documented, or can hardly be diagnosed because lack of logging/debugging output. In such cases I don't think that the problem is only at the user side...

Thanks,

Sab

--On December 21, 2007 11:22:10 AM +0100 RUMI Szabolcs rumi_ml@rtfm.hu 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, and then have a x509 hash in the ca dir. This seems to be related to some issue inside of OpenSSL. As others have noted, make sure that you can get ldapsearch -ZZ to work first.

[build@build01 zimbra]$ cat .ldaprc TLS_CACERTDIR /opt/zimbra/conf/ca

[build@build01 ca]$ pwd /opt/zimbra/conf/ca [build@build01 ca]$ ls -l total 8 lrwxrwxrwx 1 root root 6 Dec 18 12:37 3f8945a0.0 -> ca.pem -rw-r--r-- 1 root root 891 Dec 18 12:37 ca.key -rw-r--r-- 1 root root 976 Dec 18 12:37 ca.pem

for example.

--Quanah

--

Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

I got my configuration working

I have a ca.crt (a root cert from CAcert.org, you could create your own ca.crt) I have a server.key I have a server.crt (signed by ca.crt)

all setup in the slapd.conf file

I have ca.crt setup in the ldap.conf file on the slave

I happen to have TLS_VERIFY NEVER set, but I'm not sure that matters. I also have TLS_REQCERT ALLOW set, but because of above it's not used in the ldap.conf

I've set this up on Fedora, MDK, and OpenSolaris.

Sellers

On Dec 21, 2007, at 12:19 PM, Quanah Gibson-Mount wrote:

--On December 21, 2007 9:07:20 AM -0800 Quanah Gibson-Mount quanah@zimbra.com wrote:

...

--On December 21, 2007 11:22:10 AM +0100 RUMI Szabolcs <rumi_ml@rtfm.hu

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

Err, in ldap.conf or .ldaprc, I mean. ;)

--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@nitle.org AIM: imthewherd | GTalk: cgseller@gmail.com

RUMI Szabolcs rumi_ml@rtfm.hu writes:

Hello!

On Thu, 20 Dec 2007 11:03:44 -0500 "Chris G. Sellers" chris.sellers@nitle.org 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

ldaps:// is a server initiated tls session, while starttls on ldap:// is a client initiated tls session. Don't forget that syncrepl is a client connection to the server.

[...]

...

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.

as already mentioned, syncrepl is a client operation, thus ldap.conf(5) would be applicable, but slapd.conf(5) has in addition configuration parameters, just search for syncrepl.

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

read the docs carefully! And think twice!

[...]

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.

First test with openssl tools, like s_client(1).

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 do understand your frustration, but that is mostly due to not reading the proper documentation. Forget about google, the only relevant source of information is: http://www.openssl.org/docs/

I have no problems creating a valid certificate chain with the openssl tools, just modify openssl.cnf to your requirements:

./CA.pl -newca ./Ca.pl -newreq ./CA.pl -sign openssl rsa -in newreq.pem -out mykey.pem mv newcert.pem mycert.pem ./CA.pl -verify mycert.pem

-Dieter