On Sat, Apr 25, 2009 at 11:14:33PM +0200, Arthur de Jong wrote:
> I've been busy tracking down a LDAP/TLS related bug in my package
> (#521617) and found that the correct certificate checks are not done
> correctly if I only set the LDAP_OPT_X_TLS_REQUIRE_CERT option on a
> connection:
> tls_reqcert=LDAP_OPT_X_TLS_NEVER;
> ldap_set_option(NULL,LDAP_OPT_X_TLS_REQUIRE_CERT,&tls_reqcert);
> I get at entering ldap_start_tls_s():
> TLS: peer cert untrusted or revoked (0x42)
> TLS: can't connect: (unknown error code).
>
> If I set the option globally, after opening the connection:
> ldap_set_option(NULL,LDAP_OPT_X_TLS_REQUIRE_CERT,&tls_reqcert);
> I get:
> TLS: hostname (192.168.12.1) does not match common name in certificate
> (server.host.name.tld).
[snip]
> I think (but haven't investigated further) that some of the
> option-checks that are done should be done on the connection options,
> not on the global ones.
As much as I'm sure Quanah would love for everyone to upgrade to the latest
OpenLDAP release every couple of months, I don't think OpenLDAP is
misbehaving in this case.
I recently ran into a similar problem with nss_ldap wherein it was calling
ldap_set_option() on LDAP_OPT_X_TLS_REQUIRE_CERT *after* the LDAP handle was
initialized with ldap_initialize().
According to the latest (albeit expired) LDAP C API draft:
--
11.2. LDAP Session Handle Options
[...]
ld The session handle. If this is NULL, a set of global defaults is
accessed. New LDAP session handles created with ldap_init() or
ldap_open() inherit their characteristics from these global
defaults.
--
global defaults are inherited by new LDAP handles when they're initialized.
As a result, global defaults set after initializing an LDAP handle do not
apply to that handle. IOW, they're global *defaults*, not global *settings.*
AFAICT with OpenLDAP 2.4.20, it implements this part of the draft correctly.
john
--
John Morrissey _o /\ ---- __o
j...@horde.net _-< \_ / \ ---- < \,
www.horde.net/ __(_)/_(_)________/ \_______(_) /_(_)__
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
