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 -f)
PING eoan-ldap-start-tls-1835181.lxd (10.0.100.137) 56(84) bytes of data.
64 bytes from ubuntu (10.0.100.137): icmp_seq=1 ttl=64 time=0.009 ms
The certificate has a CN of "ubuntu", however, so I expect all ssl related
connections to fail unless I use that name:
ubuntu@eoan-ldap-start-tls-1835181:~$ openssl x509 -in /etc/ldap/ubuntu.pem
-noout -subject
subject=C = UK, ST = Some-State, O = Internet Widgits Pty Ltd, CN = ubuntu
Via /etc/hosts, ubuntu points at the same ip as the hostname:
ubuntu@eoan-ldap-start-tls-1835181:~$ ping -c 1 ubuntu
PING ubuntu (10.0.100.137) 56(84) bytes of data.
64 bytes from ubuntu (10.0.100.137): icmp_seq=1 ttl=64 time=0.034 ms
So let's begin!
a) SSL with incorrect name fails as expected:
ubuntu@eoan-ldap-start-tls-1835181:~$ ldapwhoami -x -H
ldaps://eoan-ldap-start-tls-1835181.lxd/
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
ubuntu@eoan-ldap-start-tls-1835181:~$ tail /var/log/syslog
Jul 9 20:39:30 eoan-ldap-start-tls-1835181 slapd[220]: conn=1002 fd=14 ACCEPT
from IP=10.0.100.137:58498 (IP=0.0.0.0:636)
Jul 9 20:39:30 eoan-ldap-start-tls-1835181 slapd[220]: conn=1002 fd=14 TLS
established tls_ssf=256 ssf=256
Jul 9 20:39:30 eoan-ldap-start-tls-1835181 slapd[220]: conn=1002 fd=14 closed
(connection lost)
Debugging shows:
ubuntu@eoan-ldap-start-tls-1835181:~$ ldapwhoami -x -H
ldaps://eoan-ldap-start-tls-1835181.lxd/ -d -1 2>&1|grep ^TLS
TLS: hostname (eoan-ldap-start-tls-1835181.lxd) does not match common name in
certificate (ubuntu).
TLS: can't connect: (unknown error code).
b) START TLS with incorrect name also fails as expected:
ubuntu@eoan-ldap-start-tls-1835181:~$ ldapwhoami -x -ZZ -h
eoan-ldap-start-tls-1835181.lxd
ldap_start_tls: Connect error (-11)
additional info: (unknown error code)
Note that the log confirms start tls was used:
ubuntu@eoan-ldap-start-tls-1835181:~$ tail /var/log/syslog
Jul 9 20:40:44 eoan-ldap-start-tls-1835181 slapd[220]: conn=1004 fd=14 ACCEPT
from IP=10.0.100.137:52990 (IP=0.0.0.0:389)
Jul 9 20:40:44 eoan-ldap-start-tls-1835181 slapd[220]: conn=1004 op=0 EXT
oid=1.3.6.1.4.1.1466.20037
Jul 9 20:40:44 eoan-ldap-start-tls-1835181 slapd[220]: conn=1004 op=0 STARTTLS
Jul 9 20:40:44 eoan-ldap-start-tls-1835181 slapd[220]: conn=1004 op=0 RESULT
oid= err=0 text=
Jul 9 20:40:44 eoan-ldap-start-tls-1835181 slapd[220]: conn=1004 fd=14 TLS
established tls_ssf=256 ssf=256
Jul 9 20:40:44 eoan-ldap-start-tls-1835181 slapd[220]: conn=1004 fd=14 closed
(connection lost)
Debugging explains why, and it's the same reason:
ubuntu@eoan-ldap-start-tls-1835181:~$ ldapwhoami -x -ZZ -h
eoan-ldap-start-tls-1835181.lxd -d -1 2>&1 | grep ^TLS
TLS: hostname (eoan-ldap-start-tls-1835181.lxd) does not match common name in
certificate (ubuntu).
TLS: can't connect: (unknown error code).
Now let's try the working case, by using "ubuntu" as the target hostname.
a) SSL works fine:
ubuntu@eoan-ldap-start-tls-1835181:~$ ldapwhoami -x -H ldaps://ubuntu/
anonymous
ubuntu@eoan-ldap-start-tls-1835181:~$ tail /var/log/syslog
Jul 9 20:42:31 eoan-ldap-start-tls-1835181 slapd[220]: conn=1006 fd=14 ACCEPT
from IP=10.0.100.137:58524 (IP=0.0.0.0:636)
Jul 9 20:42:31 eoan-ldap-start-tls-1835181 slapd[220]: conn=1006 fd=14 TLS
established tls_ssf=256 ssf=256
Jul 9 20:42:31 eoan-ldap-start-tls-1835181 slapd[220]: conn=1006 op=0 BIND
dn="" method=128
Jul 9 20:42:31 eoan-ldap-start-tls-1835181 slapd[220]: conn=1006 op=0 RESULT
tag=97 err=0 text=
Jul 9 20:42:31 eoan-ldap-start-tls-1835181 slapd[220]: conn=1006 op=1 EXT
oid=1.3.6.1.4.1.4203.1.11.3
Jul 9 20:42:31 eoan-ldap-start-tls-1835181 slapd[220]: conn=1006 op=1 WHOAMI
Jul 9 20:42:31 eoan-ldap-start-tls-1835181 slapd[220]: conn=1006 op=1 RESULT
oid= err=0 text=
Jul 9 20:42:31 eoan-ldap-start-tls-1835181 slapd[220]: conn=1006 op=2 UNBIND
Jul 9 20:42:31 eoan-ldap-start-tls-1835181 slapd[220]: conn=1006 fd=14 closed
b) START_TLS too:
ubuntu@eoan-ldap-start-tls-1835181:~$ ldapwhoami -x -ZZ -h ubuntu
anonymous
ubuntu@eoan-ldap-start-tls-1835181:~$ tail /var/log/syslog
Jul 9 20:43:28 eoan-ldap-start-tls-1835181 slapd[220]: conn=1007 op=0 STARTTLS
Jul 9 20:43:28 eoan-ldap-start-tls-1835181 slapd[220]: conn=1007 op=0 RESULT
oid= err=0 text=
Jul 9 20:43:28 eoan-ldap-start-tls-1835181 slapd[220]: conn=1007 fd=14 TLS
established tls_ssf=256 ssf=256
Jul 9 20:43:28 eoan-ldap-start-tls-1835181 slapd[220]: conn=1007 op=1 BIND
dn="" method=128
Jul 9 20:43:28 eoan-ldap-start-tls-1835181 slapd[220]: conn=1007 op=1 RESULT
tag=97 err=0 text=
Jul 9 20:43:28 eoan-ldap-start-tls-1835181 slapd[220]: conn=1007 op=2 EXT
oid=1.3.6.1.4.1.4203.1.11.3
Jul 9 20:43:28 eoan-ldap-start-tls-1835181 slapd[220]: conn=1007 op=2 WHOAMI
Jul 9 20:43:28 eoan-ldap-start-tls-1835181 slapd[220]: conn=1007 op=2 RESULT
oid= err=0 text=
Jul 9 20:43:28 eoan-ldap-start-tls-1835181 slapd[220]: conn=1007 op=3 UNBIND
Jul 9 20:43:28 eoan-ldap-start-tls-1835181 slapd[220]: conn=1007 fd=14 closed
This slapd from the distribution is built with gnutls:
ubuntu@eoan-ldap-start-tls-1835181:~$ ldd $(which slapd)|grep tls
libgnutls.so.30 => /lib/x86_64-linux-gnu/libgnutls.so.30
(0x00007f637c3e0000)
ubuntu@eoan-ldap-start-tls-1835181:~$ ldd $(which slapd)|grep ssl
ubuntu@eoan-ldap-start-tls-1835181:~$
ubuntu@eoan-ldap-start-tls-1835181:~$ apt-cache policy slapd
slapd:
Installed: 2.4.47+dfsg-3ubuntu2
Candidate: 2.4.47+dfsg-3ubuntu2
Version table:
*** 2.4.47+dfsg-3ubuntu2 500
500 http://br.archive.ubuntu.com/ubuntu eoan/main amd64 Packages
100 /var/lib/dpkg/status
Next step is to check older releases of Ubuntu.
--
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 between
ldaps:// and ldap:// with STARTTLS
Status in openldap package in Ubuntu:
Incomplete
Bug description:
This is the same bug as
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1547927 which
has been closed.
Tested and confirmed present with vivid, wily, xenial and bionic
Also logged with openldap as
http://www.openldap.org/its/index.cgi/Incoming?id=8374 however I think
that this is a packaging issue caused by using GNUTLS rather than
OpenSSL.
Important: to replicate the issue you need to connect to an LDAP
server which presents a certificate with a CN that DOES NOT MATCH the
connection URI passed to the OpenLDAP client. In practice, this is
simple enough to achieve by using the IP address of a server rather
than the FQDN.
The core of the issue is that the handling of the
LDAP_OPT_X_TLS_REQUIRE_CERT option appears to be different between
servers accessed via ldaps:// and ldap:// (plus STARTTLS) URIs.
When accessing server with an invalid certificate, the results are:
ldaps://
never OK
hard Error: can't contact LDAP server
demand Error: can't contact LDAP server
allow OK
try Error: can't contact LDAP server
ldap:// plus explicit ldap_start_tls_s()
never OK
hard OK
demand OK
allow OK
try OK
Based on all the documentation, the results should be the same between
approaches.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1835181/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
