Thank you very much for this idea. I thought I have already tried this out. I have copy the *.crt to the official dir of ssl/cert and set the access to 644. And now all works correctly.
Tobias
Am 2017-03-21 08:06, schrieb Aki Tuomi:
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@gwarband.de wrote:
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 root LetsEncrypt.pem -> /etc/ssl/own/LetsEncrypt.crt drwxr-xr-x root root / drwxr-xr-x root root etc drwxr-xr-x root root ssl drwxr-x--- root ssl-cert own -rw-r----- root ssl-cert LetsEncrypt.crt
Tobias
Am 2017-03-20 21:49, schrieb Aki Tuomi:
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 9:24 PM info@gwarband.de wrote:
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, can you try again?
Aki
On March 20, 2017 at 8:14 PM info@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 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 info@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: 2017-03-20 16:18 >> Absender: Dan White dwhite@cafedemocracy.org >> Empfänger: info@gwarband.de >> Kopie: openldap-technical@openldap.org >> >> On 03/20/17 16:06 +0100, info@gwarband.de wrote: >>>> Debug Dovecot's implementation of ldap_start_tls_s(). >>> I don't have any idea how to set a higher debug level to >>> dovecot. >>> In >>> my opinion I have the highest. So I can't deliver a greater >>> log. >> >> I recommend consulting Dovecot's advice on how to run a >> debugger, >> or >> dig >> into the code which calls libldap. > > Hi! > I just ran a quick test, and following things are needed: > > uris = ldap://ldap.host.com > tls = yes > tls_ca_cert_file = /path/to/cert-bundle.crt > > this has been tested with 2.2.28, and works just fine. Not sure > why > you are having issues. > > Of course this could be anything between not finding compatible > ciphers to the LDAP server actually expecting client > certificate, > what > with the logs not actually being too verbose unfortunately. > There > isn't too much to "debug" in Dovecot's TLS implementation, it's > not > doing anything fancy asides from calling the ldap_start_tls_s. > > I am not sure what debugging you could try further. > > Aki