7:55 a.m.
--On Friday, June 02, 2017 11:01 AM +0200 r0m5 <r0m5(a)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>
8:46 a.m.
New subject: problem with syncrepl and STARTTLS
Le 2017-06-02 16:55, Quanah Gibson-Mount a écrit :
--On Friday, June 02, 2017 11:01 AM +0200 r0m5 <r0m5(a)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 !
1:31 a.m.
New subject: problem with syncrepl and STARTTLS
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(a)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,
5:13 a.m.
New subject: problem with syncrepl and STARTTLS
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.
6:07 a.m.
New subject: problem with syncrepl and STARTTLS
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.
6:14 a.m.
New subject: problem with syncrepl and STARTTLS
r0m5 wrote:
Le 2017-08-09 14:13, Michael Ströder a écrit :
> 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?!?
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.
Yes, therefore I'd see ITS#8427 resolved as do-not-use-broken-certs.
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
[..]
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.
Then this sounds like PHP-LDAP being broken.
Ciao, Michael.
2309
days inactive
2377
days old
openldap-technical@openldap.org
6 comments
4 participants
participants (4)
-
Michael Ströder -
Quanah Gibson-Mount -
r0m5 -
Ryan Tandy