Hi!
I've recreated my certificate/key pair, beacuse I can't seem get over this issue. I've changed the hostname in the certificate to the ip address of the server. OpenLDAP 2.4.11, Debian testing/lenny system.
Could someone tell me why this would fail: $ 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)
That last "TLS:" prefixed message bothers me; it tells me that 192.168.1.3 doesn't match with 192.168.1.3?! Why?
Daniel
On Fri, 31 Oct 2008, LÉVAI Dániel wrote:
I've recreated my certificate/key pair, beacuse I can't seem get over this issue. I've changed the hostname in the certificate to the ip address of the server. OpenLDAP 2.4.11, Debian testing/lenny system.
...
TLS: hostname (192.168.1.3) does not match common name in certificate (192.168.1.3).
...
That last "TLS:" prefixed message bothers me; it tells me that 192.168.1.3 doesn't match with 192.168.1.3?! Why?
Hmm, you mention "Debian testing/lenny". Does that mean it uses GNUtls? Due to differences in APIs, OpenLDAP uses different routines to perform the "check hostname against certificate" test depending on whether it's built against OpenSSL or GNUtls. 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.)
I suggest you file an ITS about that.
Philip Guenther
Philip Guenther wrote:
On Fri, 31 Oct 2008, LÉVAI Dániel wrote:
I've recreated my certificate/key pair, beacuse I can't seem get over this issue. I've changed the hostname in the certificate to the ip address of the server. OpenLDAP 2.4.11, Debian testing/lenny system.
...
TLS: hostname (192.168.1.3) does not match common name in certificate (192.168.1.3).
...
That last "TLS:" prefixed message bothers me; it tells me that 192.168.1.3 doesn't match with 192.168.1.3?! Why?
Hmm, you mention "Debian testing/lenny". Does that mean it uses GNUtls?
Yes, unfortunately, this is a tendency with Debian. They make almost all packages link against GnuTLS because some licensing issues.
Due to differences in APIs, OpenLDAP uses different routines to perform the "check hostname against certificate" test depending on whether it's built against OpenSSL or GNUtls. 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.)
I suggest you file an ITS about that.
Philip Guenther
Thanks! So, it bugged me, and I've compiled a 2.4.12-Release with OpenSSL support on the exact same machine, while keeping the Debian package (with GnuTLS) too. Guess what, it works like charm with the slapd(8) binary linked against OpenSSL... With the exact same cert/key pair, with the IP address as the CN, with OpenSSL there is no error. Above all, the strange thing, is with the clients; one of the client is a Debian system too, with ldapsearch linked against GnuTLS. The client's ldapsearch won't work (!!!) with the server which uses OpenSSL. This is what is happening: $ ldapsearch -d 1 -Wx '(objectclass=*)' -H ldaps://192.168.1.3 ldap_url_parse_ext(ldaps://192.168.1.3) ldap_create ldap_url_parse_ext(ldaps://192.168.1.3:636/??base) Enter LDAP Password: ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP 192.168.1.3:636 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 192.168.1.3:636 ldap_pvt_connect: fd: 3 tm: -1 async: 0
^^^ that's it, it hangs.
With strace(1), the output is this: [...] socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 3
write(2, "ldap_new_socket: 3\n"..., 19ldap_new_socket: 3
) = 19
fcntl(3, F_SETFD, FD_CLOEXEC) = 0
write(2, "ldap_prepare_socket: 3\n"..., 23ldap_prepare_socket: 3
) = 23
setsockopt(3, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0
setsockopt(3, SOL_TCP, TCP_NODELAY, [1], 4) = 0
write(2, "ldap_connect_to_host: Trying 192."..., 45ldap_connect_to_host: Trying 192.168.1.3:636
) = 45
write(2, "ldap_pvt_connect: fd: 3 tm: -1 as"..., 40ldap_pvt_connect: fd: 3 tm: -1 async: 0
) = 40
connect(3, {sa_family=AF_INET, sin_port=htons(636), sin_addr=inet_addr("192.168.1.3")}, 16) = 0 [...]
munmap(0x7fbacf8b8000, 282624) = 0 getrusage(RUSAGE_SELF, {ru_utime={0, 168010}, ru_stime={0, 32002}, ...}) = 0 times({tms_utime=16, tms_stime=3, tms_cutime=0, tms_cstime=0}) = 1754251173 getrusage(RUSAGE_SELF, {ru_utime={0, 168010}, ru_stime={0, 32002}, ...}) = 0 times({tms_utime=16, tms_stime=3, tms_cutime=0, tms_cstime=0}) = 1754251173 getrusage(RUSAGE_SELF, {ru_utime={0, 168010}, ru_stime={0, 32002}, ...}) = 0 times({tms_utime=16, tms_stime=3, tms_cutime=0, tms_cstime=0}) = 1754251173 write(3, "\26\3\2\0X\1\0\0T\3\2I\16\336\310\353\203\363\324\36\273S\4\f5\240\240\10\26\20\264^\212"..., 93) = 93 read(3, "\26\3\1\0J"..., 5) = 5 read(3, "\2\0\0F\3\1I\16\336\310u*^\343)\17\0375\4L\34_\33\244\327\325T\342?\310C\240g"..., 74) = 74 read(3, "\26\3\1\6a"..., 5) = 5 read(3, "\v\0\6]\0\6Z\0\2y0\202\2u0\202\1\336\2\1\0000\r\6\t*\206H\206\367\r\1\1"..., 1633) = 1633 brk(0xe78000) = 0xe78000 read(3, "\26\3\1@\0"..., 5) = 5 read(3, "\r\0M*\3\1\2@M$\0A0?1$0"\6\3U\4\n\23\33Digital "..., 16384) = 12758 read(3,
^^^ that is when it hangs. If somebody is interested in the full strace(1) log, I'll provide it gladly :)
Philip, I'd like to report this issue, but I'm not sure to which softwares's tracker? What is the hunch regarding this; is this a GnuTLS issue, or is this an OpenLDAP issue. Though, after reporting to upstream I should report this to Debian BTS (at least I think).
Daniel
On Mon, 3 Nov 2008, LÉVAI Dániel wrote:
Philip Guenther wrote:
...
Due to differences in APIs, OpenLDAP uses different routines to perform the "check hostname against certificate" test depending on whether it's built against OpenSSL or GNUtls. 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.)
...
So, it bugged me, and I've compiled a 2.4.12-Release with OpenSSL support on the exact same machine, while keeping the Debian package (with GnuTLS) too. Guess what, it works like charm with the slapd(8) binary linked against OpenSSL... With the exact same cert/key pair, with the IP address as the CN, with OpenSSL there is no error. Above all, the strange thing, is with the clients; one of the client is a Debian system too, with ldapsearch linked against GnuTLS. The client's ldapsearch won't work (!!!) with the server which uses OpenSSL. This is what is happening: $ ldapsearch -d 1 -Wx '(objectclass=*)' -H ldaps://192.168.1.3
...
If somebody is interested in the full strace(1) log, I'll provide it gladly :)
Philip, I'd like to report this issue, but I'm not sure to which softwares's tracker? What is the hunch regarding this; is this a GnuTLS issue, or is this an OpenLDAP issue. Though, after reporting to upstream I should report this to Debian BTS (at least I think).
There are at least two distinct issues here.
The handling of CN=IP-address by OpenLDAP when using GNUtls is an issue in OpenLDAP and should be filed as an ITS at www.openldap.org.
The hang when a client using GNUtls connects to a server using OpenSSL and the failures when both client and server are using GNUtls should, IMO, both be taken up with Debian. They're the ones who think GNUtls should be used; they're the one who should be hearing when it doesn't work and dealing with issues with it.
Philip Guenther
openldap-software@openldap.org
-
LÉVAI Dániel -
Philip Guenther