Le 2017-06-02 17:46, r0m5 a écrit :

Le 2017-06-02 16:55, Quanah Gibson-Mount a écrit : --On Friday, June 02, 2017 11:01 AM +0200 r0m5 r0m5@r0m5.eu wrote:

Hello,

I am facing an issue with syncrepl and STARTTLS on 389 port. The kind of problem happening only sometimes, and disappearing "by itself". I use Debian Jessie, OpenLDAP 2.4.40+dfsg-1+deb8u2. 2.4.40 is 2.5 years old, 5 point releases behind, and had significant known replication issues. I believe there is a build of 2.4.44 in backports for Jessie. I would advise using that instead.

As far as debug logging, you would need to use "-d -1" to slapd, rather than attempting to set the loglevel to -1, as some debug logging is only possible via the slapd daemon. But your first step is to move to a current release.

--Quanah

--

Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com

Hello !

Thanks for your reply. I just upgraded the preproduction environment provider and consumers to the jessie-backports version. I will check the prod to preprod injections during the next days then let you know.

Have a good weekend !

Hello !

I upgraded to 2.4.44 but still had problems (less, though). So I used "-d -1" with slapd instead of olcLoglevel as you said then I noticed there was a problem with certificate validation even with using demand or allow for TLS reqcert in olcSyncrepl and in /etc/ldap/ldap.conf. I was at that time using self-signed certificates.

So I set up a PKI and now it looks OK regarding syncrepl. So I guess my problem might be related to ITS#8427, which I didn't see before posting here.

I still have issues though, with applications randomly failing STARTTLS to my consumers :-(

Regards,

Le 2017-08-09 14:13, Michael Ströder a écrit :

r0m5 wrote:

...

So I set up a PKI and now it looks OK regarding syncrepl. So I guess my problem might be related to ITS#8427, which I didn't see before posting here.

I still have issues though, with applications randomly failing STARTTLS to my consumers

Many problems like this are caused by not getting the PKI to issue correct public-key certs. Especially you should put all DNS names a LDAP client might use to connect to your LDAP server in subjectAltName extension.

E.g. ITS#8427 says: "Provide the servers with TLS certificates that are correct but do not include an address used in syncrepl provider setting." What the heck does that mean?!?

Ciao, Michael.

I guess the guy uses in order to reproduce a provider certificate which is signed by a CA his consumer trusts, but the consumer connects to the provider using a DNS name different from the certificate CN and not included in subjectAltName.

The certificate I used when I had the problem was self signed but my consumer was connecting to a correct DNS name (the CN of the certificate).

In both cases the certificate is not "valid", but apparently for different reasons.

Regarding my applications randomly failing STARTTLS to my consumers, it's not related to the use of a DNS name different from the certificate CN and not included in subjectAltName. Considering an application using always the same DNS name to connect to the consumer and connecting to the same consumer which presents always the same certificate (self-signed) : most of the time this application succeeds STARTTLS, but sometimes fails. Log on the consumer :

conn=3232 fd=20 ACCEPT from IP=192.168.74.222:50187 (IP=0.0.0.0:389) conn=3232 op=0 EXT oid=1.3.6.1.4.1.1466.20037 conn=3232 op=0 STARTTLS conn=3232 op=0 RESULT oid= err=0 text= conn=3232 fd=20 TLS established tls_ssf=128 ssf=128 conn=3232 fd=20 closed (connection lost)

I will dig more into it. So far it appears than only PHP applications fail this way, it seems like there are no probrems with STARTTLS from freeradius or Apache Basic AuthType with AuthBasicProvider ldap.

On Wed, Aug 09, 2017 at 10:31:03AM +0200, r0m5 wrote:

I still have issues though, with applications randomly failing STARTTLS to my consumers :-(

Are you still using the TLS_REQCERT option? If you are, you could be seeing ITS#8385.