Your message dated Wed, 18 Feb 2009 15:30:36 +0100
with message-id <200902181530.36758.g...@dcmr.polytechnique.fr>
and subject line Close bug report
has caused the Debian Bug report #515913,
regarding libldap: TLS failure when using IP adresses
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
515913: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=515913
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: libldap-2.4-2
Version: 2.4.11-1
Severity: important
File: libldap
Hi,
I ran in this problem with the upgrade from sarge to lenny. At first I
thought it was an issue related to GnuTLS (like bug #514578), but the
error message I get in the debug mode seem to point out towards libldap.
When attempting to connect to a slapd server using TLS, with the URI
containing an IP adress, the connection fails. It seems that ibpam-ldap
and libnss-ldap are also affected.
The error message that seems confusing is:
TLS: hostname (129.104.26.101) does not match common name in certificate
(129.104.26.101).
Here is the outputs of ldapsearch and gnutls_cli that seem to indicate
that the problem is related to libldap and not to libgnutls, since
gnutls-cli connects without problem.
g...@berlioz:~$ ldapsearch -x ldaps://129.104.26.101 -d 5
ldap_create
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP 129.104.26.101:636
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying 129.104.26.101:636
ldap_pvt_connect: fd: 3 tm: -1 async: 0
TLS: hostname (129.104.26.101) does not match common name in certificate
(129.104.26.101).
ldap_err2string
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
g...@berlioz:~$ gnutls-cli -p ldaps --x509cafile
/etc/ldap/ssl/certs/dcmr-cacert.pem 129.104.26.101
Processed 1 CA certificate(s).
Resolving '129.104.26.101'...
Connecting to '129.104.26.101:636'...
- Certificate type: X.509
- Got a certificate list of 2 certificates.
- Certificate[0] info:
# The hostname in the certificate matches '129.104.26.101'.
# valid since: Wed Feb 18 09:20:09 CET 2009
# expires at: Thu Feb 18 09:20:09 CET 2010
# fingerprint: 4F:9E:C8:CA:EF:A6:B6:ED:5A:E7:AD:B7:B0:69:69:2F
# Subject's DN: C=FR,ST=France,O=DCMR - Ecole
Polytechnique,CN=129.104.26.101
# Issuer's DN: O=DCMR - Ecole
Polytechnique,OU=DCMR,EMAIL=[REMOVED],L=Palaiseau,ST=France,C=FR,CN=DCMR
Root CA
- Certificate[1] info:
# valid since: Thu Jan 11 10:35:48 CET 2007
# expires at: Sun Jan 8 10:35:48 CET 2017
# fingerprint: CA:80:AF:D4:9B:3E:46:35:91:B9:BD:F5:59:BA:B6:56
# Subject's DN: O=DCMR - Ecole
Polytechnique,OU=DCMR,EMAIL=[REMOVED],L=Palaiseau,ST=France,C=FR,CN=DCMR
Root CA
# Issuer's DN: O=DCMR - Ecole
Polytechnique,OU=DCMR,EMAIL=[REMOVED],L=Palaiseau,ST=France,C=FR,CN=DCMR
Root CA
- Peer's certificate is trusted
- Version: TLS1.0
- Key Exchange: RSA
- Cipher: AES-128-CBC
- MAC: SHA1
- Compression: NULL
- Handshake was completed
- Simple Client Mode:
Guillaume
-- System Information:
Debian Release: 5.0
APT prefers stable
APT policy: (500, 'stable')
Architecture: i386 (i686)
Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages libldap-2.4-2 depends on:
ii libc6 2.7-18 GNU C Library: Shared libraries
ii libgnutls26 2.4.2-6 the GNU TLS library - runtime libr
ii libsasl2-2 2.1.22.dfsg1-23 Cyrus SASL - authentication abstra
libldap-2.4-2 recommends no packages.
libldap-2.4-2 suggests no packages.
-- no debconf information
--- End Message ---
--- Begin Message ---
Sorry for the trouble:
I just found out that this was not a bug, but the expected behaviour, as per
RFC 4513 and Section 16.1.1 from the OpenLDAP Administrator's Guide: the
client is expecting a certificate in which the CN is a fully-qualified domain
name and not an IP address.
For completedness, and if anyone gets in the same sort of problems, the
migration of Openldap from etch to lenny requires to:
- change server certificates with a signature chain that does not include an
RSA-MD5 signature (as required by GnuTLS, and which was not by OpenSSL in the
previous version).
- make sure that the FQDN is used in the CN of the server. Other identification
elements, such as IP address are to be added as subjectAltName in this
certificate.
Guillaume
--- End Message ---
