I'm not quite sure if it's the same thing as is happening here, but
we've basically just had our entire infrastructure broken because it
relies on LDAP over SSL.
It seems that the newest release of libgnutls13 (2.0.4-1ubuntu2.3),
which was supposed to fix a " where some valid certificate chains would
be untrusted", ironically breaks our (valid) certificate chain.
The following is a log of a machine which had not yet been updated,
basically enabling me to point the finger at libgnutls:
r...@xibalba246:~# apt-cache policy libgnutls13
libgnutls13:
Installed: 2.0.4-1ubuntu2.1
Candidate: 2.0.4-1ubuntu2.3
Version table:
2.0.4-1ubuntu2.3 0
500 http://ch.archive.ubuntu.com hardy-updates/main Packages
500 http://security.ubuntu.com hardy-security/main Packages
*** 2.0.4-1ubuntu2.1 0
100 /var/lib/dpkg/status
2.0.4-1ubuntu2 0
500 http://ch.archive.ubuntu.com hardy/main Packages
r...@xibalba246:~# ldapsearch -x -H ldaps://xibalba233.cs.unibas.ch/ -D
cn=xxxcensored,dc=dbis,dc=cs,dc=unibas,dc=ch -w xxxcensored -b
"dc=dbis,dc=cs,dc=unibas,dc=ch" -s sub
'(&(objectclass=posixAccount)(uid=xxxcensored))'
# extended LDIF
#
# LDAPv3
# base <dc=dbis,dc=cs,dc=unibas,dc=ch> with scope subtree
# filter: (&(objectclass=posixAccount)(uid=xxxcensored))
# requesting: ALL
#
[...]
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
r...@xibalba246:~# apt-get -y -q install libgnutls13
Reading package lists...
Building dependency tree...
Reading state information...
Suggested packages:
gnutls-bin
The following packages will be upgraded:
libgnutls13
1 upgraded, 0 newly installed, 0 to remove and 56 not upgraded.
Need to get 0B/307kB of archives.
After this operation, 0B of additional disk space will be used.
(Reading database ... 24099 files and directories currently installed.)
Preparing to replace libgnutls13 2.0.4-1ubuntu2.1 (using
.../libgnutls13_2.0.4-1ubuntu2.3_i386.deb) ...
Unpacking replacement libgnutls13 ...
Setting up libgnutls13 (2.0.4-1ubuntu2.3) ...
Processing triggers for libc6 ...
ldconfig deferred processing now taking place
r...@xibalba246:~# ldapsearch -x -H ldaps://xibalba233.cs.unibas.ch/ -D
cn=xxxcensored,dc=dbis,dc=cs,dc=unibas,dc=ch -w xxxcensored -b
"dc=dbis,dc=cs,dc=unibas,dc=ch" -s sub
'(&(objectclass=posixAccount)(uid=xxxcensored))'
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
r...@xibalba246:~#
As said, since our user management is in LDAP (pam_ldap), we're currently
losing our servers one by one ;-)
Anyway, these machines are not publicly accessible, so you won't be able
to immediately test it for yourself. However, there is a *web* server
which is using the same certificate chain (just a different CN),
available at https://dbis.cs.unibas.ch/
If you contact anybody from the team there (at the mentioned website,
that is), we will gladly help you with more details, if required.
One final note: I'm definitely sure that the certificate chain as
absolutely correct (and none of them is about to expire anytime soon).
This setup has been working for months now in all kinds of SSL/TLS-
encrypted settings.
We'd be happy to see this fixed :-D
--
LDAP Authentication problem : ldap_simple_bind_s() failed
https://bugs.launchpad.net/bugs/306897
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
