[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: TLS problems with OpenLDAP

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

--
LEVAI Daniel
PGP key ID = 0x4AC0A4B1
Key fingerprint = D037 03B9 C12D D338 4412  2D83 1373 917A 4AC0 A4B1