(ITS#5789) using IP address in CN with GnuTLS

[leva@ecentrum.hu]

Full_Name: LÉVAI Dániel
Version: 2.4.11
OS: Linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (78.131.56.68)


I'm using OpenLDAP 2.4.11 on a Debian testing/lenny system.
The GnuTLS version is 2.4.2.

So I'm having a lot of problems using OpenLDAP with GnuTLS, and I've decided to
take another route in troubleshooting; I've recreated my cert/key pair, using my
machine's ip address in the CN field.
The weirdest thing happened:
$ ldapsearch -d 1 -ZZWx '(objectclass=*)' -H ldap://192.168.1.3
ldap_url_parse_ext(ldap://192.168.1.3)
ldap_create
ldap_url_parse_ext(ldap://192.168.1.3:389/??base)
ldap_extended_operation_s
ldap_extended_operation
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP 192.168.1.3:389
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying 192.168.1.3:389
ldap_pvt_connect: fd: 3 tm: -1 async: 0
ldap_open_defconn: successful
ldap_send_server_request
ber_scanf fmt ({it) ber:
ber_scanf fmt ({) ber:
ber_flush2: 31 bytes to sd 3
ldap_result ld 0x6120a0 msgid 1
wait4msg ld 0x6120a0 msgid 1 (infinite timeout)
wait4msg continue ld 0x6120a0 msgid 1 all 1
** ld 0x6120a0 Connections:
* host: 192.168.1.3  port: 389  (default)
  refcnt: 2  status: Connected
  last used: Fri Oct 31 22:36:46 2008


** ld 0x6120a0 Outstanding Requests:
 * msgid 1,  origid 1, status InProgress
   outstanding referrals 0, parent count 0
  ld 0x6120a0 request count 1 (abandoned 0)
** ld 0x6120a0 Response Queue:
   Empty
  ld 0x6120a0 response count 0
ldap_chkResponseList ld 0x6120a0 msgid 1 all 1
ldap_chkResponseList returns ld 0x6120a0 NULL
ldap_int_select
read1msg: ld 0x6120a0 msgid 1 all 1
ber_get_next
ber_get_next: tag 0x30 len 12 contents:
read1msg: ld 0x6120a0 msgid 1 message type extended-result
ber_scanf fmt ({eAA) ber:
read1msg: ld 0x6120a0 0 new referrals
read1msg:  mark request completed, ld 0x6120a0 msgid 1
request done: ld 0x6120a0 msgid 1
res_errno: 0, res_error: <>, res_matched: <>
ldap_free_request (origid 1, msgid 1)
ldap_free_connection 0 1
ldap_free_connection: refcnt 1
ldap_parse_extended_result
ber_scanf fmt ({eAA) ber:
ldap_parse_result
ber_scanf fmt ({iAA) ber:
ber_scanf fmt (}) ber:
ldap_msgfree
TLS: hostname (192.168.1.3) does not match common name in certificate 
(192.168.1.3).
ldap_err2string
ldap_start_tls: Connect error (-11)

So it seems, according to OpenLDAP, 192.168.1.3 != 192.168.1.3. Why is that?

And please allow me include some additional information, which was told me by
Philip Guenther on openldap-software@:
"It appears the routine used with GNUtls 
refuses to match IP addresses against a CN subjects component, thus 
explaining that weird message.

(In ldap_pvt_tls_check_hostname(), 'len1' is only non-zero if the hostname 
doesn't look like an IPv6 or IPv4 address, while the subject CN test needs 
'len1' to be the same as the length of the CN value.)"

Daniel