Thanks for getting back to us!
Just to be sure, I also checked xenial and trusty, and the results are the same:
ubuntu@xenial-ldap-start-tls-1835181:~$ ldapwhoami -x -H
ldaps://xenial-ldap-start-tls-1835181.lxd/ -d -1 2>&1 | grep ^TLS
TLS: hostname (xenial-ldap-start-tls-1835181.lxd) does not
Thanks for all the debug effort!
I've gone back and double-checked the code that was causing the failure,
and at some point during the testing it had been changed so that the
return from ldap_start_tls_s wasn't being checked (as it always returned
true), and instead a check was being made against
Same thing on bionic now.
a) SSL with incorrect name fails as expected:
ubuntu@bionic-ldap-start-tls-1835181:~$ sudo truncate -s 0 /var/log/syslog
ubuntu@bionic-ldap-start-tls-1835181:~$ ldapwhoami -x -H
ldaps://bionic-ldap-start-tls-1835181.lxd
ldap_sasl_bind(SIMPLE): Can't contact LDAP
I didn't have TLS_REQCERT set in /etc/ldap/ldap.conf during these tests,
but the manpage says the value "demand" (equal to "hard") is the default
in eoan at least.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openldap in
It seems to be working fine in eoan. I setup a CA and issued a server
certificate, and setup openldap with ssl/start_tls.
The hostname of the container:
ubuntu@eoan-ldap-start-tls-1835181:~$ hostname -f
eoan-ldap-start-tls-1835181.lxd
ubuntu@eoan-ldap-start-tls-1835181:~$ ping -c 1 $(hostname
I think it falls into the gaps between the various packaging approaches
and distributions.
>From the discussions with the OpenLDAP chaps, they were pretty confident
that they couldn't replicate the issue with the package built against
OpenSSL, plus there was some talk of issue being related to a
** Changed in: openldap (Ubuntu)
Status: New => Incomplete
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openldap in Ubuntu.
https://bugs.launchpad.net/bugs/1835181
Title:
OpenLDAP LDAP_OPT_X_TLS_REQUIRE_CERT
Apologies for misinterpreting this issue when initially triaging it - I
have re-marked it as Security. I notice from your linked bug report that
this was still happening with the upstream code as of September 2016 -
but upstream did not appear to engage on the issue. Can you confirm
whether this
** Information type changed from Public to Public Security
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openldap in Ubuntu.
https://bugs.launchpad.net/bugs/1835181
Title:
OpenLDAP LDAP_OPT_X_TLS_REQUIRE_CERT handling
https://cwe.mitre.org/data/definitions/295.html
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openldap in Ubuntu.
https://bugs.launchpad.net/bugs/1835181
Title:
OpenLDAP LDAP_OPT_X_TLS_REQUIRE_CERT handling differences
And just to add a real world example. If you use one of the dependent
packages (apache, exim, squid, samaba, php, postress etc.) and use LDAP
for your auth, then the SSL is worthless and anyone with access to the
network can intercept and recover the credentials in the
request/response.
--
You
De nada: my pleasure.
Just to make sure that the issue is clear though, it's worth spelling it
out.
The core of the issue is that in it's present form (and going back
multiple distributions) the default configuration for connections using
SSL via STARTTLS (which is the norm) does not check the
** Information type changed from Private Security to Public
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openldap in Ubuntu.
https://bugs.launchpad.net/bugs/1835181
Title:
OpenLDAP LDAP_OPT_X_TLS_REQUIRE_CERT handling
13 matches
Mail list logo
