similar to: Dovecot can't connect to openldap over starttls

Hello, I have also installed LE certs. But nothing helps, I have double-checking all certs. ldapsearch with -ZZ works see: https://gwarband.de/openldap/ldapsearch.log I have also uploaded the TLSCACertificateFile, maybe I have a failure in the merge of the two fiels: https://gwarband.de/openldap/LetsEncrypt.crt And also I have uploaded my complete openldap configuration:

I've replicate the settings from ldapsearch to dovecot but no success. To the certificate: Yes it's a *.crt file but I have linked the *.pem file to it and dovecot has read access to that file. I have enabled the debugging in dovecot and have uploaded the output: https://gwarband.de/openldap/dovecot-connect.log And the other site with ldapsearch:

The serverlog of openldap with loglevel "any": https://gwarband.de/openldap/openldap-connect.log Note: openldap waits 1 Minute before he says "TLS negotiation failure" after the connect. and dovecot says direct "Connect error" I've also delete the TLSCipherSuite from openldap. Tobias Am 2017-03-18 14:01, schrieb Tomas Habarta: > Increase log level on server

I've tested your soulution, but it also says the same error. I've tested all combinations of: - tls_ca_cert_file = <cert> - tls = yes - tls_require_cert = demand Every time it says "Connection error". Only when tls is uncommented it says "TLS required". Additional information from my contact with the openldap-technical mailing list: The

Hi, been running Dovecot 2.2.27 against OpenLDAP 2.4.40 normally over the unix socket on the same machine, but tried over inet with STARTTLS and it's working ok... I would suggest double-checking key/certs setup on OpenLDAP side; for the test I have used LE certs, utilizing following cn=config attributes: olcTLSCertificateKeyFile contains private key olcTLSCertificateFile contains

Well, if ldapsearch works, try to replicate its settings for dovecot client. It's not obvious what settings ldapsearch uses, have a look at default client settings in /etc/openldap/ldap.conf, there may be something set a slightly different way. Also double check permissions for files used by dovecot, I mean mainly the file listed for tls_ca_cert_file as dovecot may not have an access for

Increase log level on server side as well to see what the server says... You may remove anything in TLSCipherSuite for the purpose of testing too. Hopefully anyone knowing OpenLDAP internals could help you analyse it more deeply. Tomas On 03/18/2017 01:31 PM, info at gwarband.de wrote: > I've replicate the settings from ldapsearch to dovecot but no success. > To the certificate: >

I've finally managed that running on Debian 8 test machine by commenting tls_ca_cert_file = option from dovecot-ldap.conf, so only tls = yes tls_require_cert = demand Not sure why is that as on my CentOS6 Dovecot works even with that commented option. May be that CentOS and Debian uses different ldap library or different versions or there's another peculiarity ... Anyway, when

Actually, I likely managed to replicate the problem itself. I've observed described behavior (timeout with connection error) only if Dovecot's tls_ca_cert_file provided either non-existent file or there was no read access to the existing file -- found during review after sending my last post as I run CentOS, not Debian and didn't adjust the path correctly (/etc/ldap vs. /etc/openldap)

I have a new pcap from beginning to the end with openldap "TLS negoiation failed" https://gwarband.de/openldap/tracefile.dump The sourceports are 45376 and 45377 Tobias Am 2017-03-20 19:59, schrieb Aki Tuomi: > Well, those actually *reduce* the possible algorithms that can be > used, so uncommenting those can make things worse. > > Anyways, your pcap seems incomplete,

The one that works fine was my openxchange server, that loads contacts from openldap. In my opinion I don't have installed a security framework list SELinux or AppArmor. The output of namei -l /etc/ssl/certs/LetsEncrypt.pem f: /etc/ssl/certs/LetsEncrypt.pem drwxr-xr-x root root / drwxr-xr-x root root etc drwxr-xr-x root root ssl drwxr-xr-x root root certs lrwxrwxrwx root

I have also tested with 2.2.28 and this version has the same issue. The finding of compatible ciphers is not the problem because I have uncommented the ldap entrys: TLSCipherSuite SECURE128:-ARCFOUR-128:-CAMELLIA-128-CBC:-3DES-CBC:-CAMELLIA-128-GCM TLSProtocolMin 3.1 Maybe you have further ideas. Am 2017-03-20 17:42, schrieb Aki Tuomi: >> On March 20, 2017 at 5:28 PM

Can sombody say something about this request? This is an email from the openldap-technical mailinglist from openldap. Systemdetails are mention in the other email. -------- Originalnachricht -------- Betreff: Re: Dovecot can't connect to openldap over starttls Datum: 2017-03-20 16:18 Absender: Dan White <dwhite at cafedemocracy.org> Empf?nger: info at gwarband.de Kopie:

Hi, I'm working hard to setup winbind and openLDAP work together with TLS My networks contains: - a windows server 2008 R2 domain controller - a debian 6 based file server (openmediavault v0.4) running OpenLDAP 2.4.23 and Samba v3.5.6 - a debian 7 computer running winbind 3.6.6 I want to let OpenLDAP store SID <=> uig/gid mapping to ensure constant uid and gid for users on all linux

Did you do some succesful lookup with something there? I can see few failed attempts and one that seems to have worked just fine. As pointed out earlier, are you using security frameworks like SELinux or AppArmor? Also, can you provide namei -l /etc/ssl/certs/LetsEncrypt.pem The failed attempts are really short, indicating a VERY early problem with SSL handshake. Aki > On March 20, 2017 at

Could you copy LetsEncrypt.pem to a world-readable location, with world-readable rights, and see if this helps with your problem. I saw you tried with cat using su(do), but unfortunately supplementary groups are not always used with processes. Aki On 20.03.2017 23:09, info at gwarband.de wrote: > The one that works fine was my openxchange server, that loads contacts > from openldap. >

Well, those actually *reduce* the possible algorithms that can be used, so uncommenting those can make things worse. Anyways, your pcap seems incomplete, can you try again? Aki > On March 20, 2017 at 8:14 PM info at gwarband.de wrote: > > > I have also tested with 2.2.28 and this version has the same issue. > > The finding of compatible ciphers is not the problem because I

> On March 20, 2017 at 5:28 PM info at gwarband.de wrote: > > > Can sombody say something about this request? > > This is an email from the openldap-technical mailinglist from openldap. > > Systemdetails are mention in the other email. > > -------- Originalnachricht -------- > Betreff: Re: Dovecot can't connect to openldap over starttls > Datum:

On 07/25/2015 11:45 AM, Jake Shipton wrote: > I think a better solution to suite both worlds would be to simply have a > boot flag on the installation media such as maybe > "passwordcheck=true/false" https://xkcd.com/1172/ It's practically a law that every time someone's workflow is broken, they request an option to change it. Personally, I'm against it. Putting

On Sat, Jul 25, 2015 at 11:16:18AM -0600, Chris Murphy wrote: > On Sat, Jul 25, 2015 at 9:40 AM, Scott Robbins <scottro at nyc.rr.com> wrote: > > This might show up twice, I think I sent it from a bad address previously. > > If so, please accept my apologies. > > > > > > In Fedora 22, one developer (and only one) decided that if the password > >