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