[horde] Horde LDAP TLS not working, system LDAP TLS does

Tue Feb 19 10:32:16 UTC 2013

----- Message from Ralf Lang <lang at b1-systems.de> ---------
    Date: Tue, 19 Feb 2013 11:00:41 +0100
    From: Ralf Lang <lang at b1-systems.de>
Subject: Re: [horde] Horde LDAP TLS not working, system LDAP TLS does
      To: horde at lists.horde.org

> On 19.02.2013 10:53, Simon Wilson wrote:
>> ----- Message from Simon Wilson <simon at simonandkate.net> ---------
>> Date: Tue, 19 Feb 2013 06:49:07 +1000 From: Simon Wilson
>> <simon at simonandkate.net> Subject: Re: [horde] Horde LDAP TLS not
>> working, system LDAP TLS does To: Ralf Lang <lang at b1-systems.de>
>> Cc: "horde at lists.horde.org" <horde at lists.horde.org>
>>
>>
>>> On 19/02/2013, at 2:07 AM, Ralf Lang <lang at b1-systems.de> wrote:
>>>
>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>>>
>>>> On 18.02.2013 16:30, Simon Wilson wrote:
>>>>> I am going crazy with this one...
>>>>>
>>>>> My H5 setup has been working fine for a week. Earlier in the
>>>>> week I updated the certificates that the systems use, but
>>>>> missed one on the new Horde server, and today everything
>>>>> stopped working with certificate expired errors.
>>>>>
>>>>> I worked out where I had missed it, put it there, but now
>>>>> Horde can't auth using TLS (it has been fine):
>>>>>
>>>>> 2013-02-18T14:56:45+00:00 EMERG: HORDE TLS not started:
>>>>> Connect error [pid 7145 on line 514 of
>>>>> "/usr/share/pear/Horde/Ldap.php"]
>>>>>
>>>>> It drops a fatal error whenever TLS is enabled. The certs
>>>>> appear fine, and Imp using the same certs can connect to the
>>>>> separate IMAP server.
>>>>>
>>>>> My old Horde 4 server can connect fine over TLS, so it's not
>>>>> the LDAP server.
>>>>>
>>>>> The strange thing though is that I can ldapsearch from the
>>>>> new system using TLS:
>>>>>
>>>>> ldapsearch -ZZ -x -b dc=simonandkate,dc=lan
>>>>>
>>>>> Generates this on the LDAP server:
>>>>>
>>>>> Feb 19 01:15:57 emp01 slapd[3297]: conn=2378 fd=48 ACCEPT
>>>>> from IP=192.168.1.230:35382 (IP=0.0.0.0:389) Feb 19 01:15:57
>>>>> emp01 slapd[3297]: conn=2378 op=0 EXT
>>>>> oid=1.3.6.1.4.1.1466.20037 Feb 19 01:15:57 emp01 slapd[3297]:
>>>>> conn=2378 op=0 STARTTLS Feb 19 01:15:57 emp01 slapd[3297]:
>>>>> conn=2378 op=0 RESULT oid= err=0 text= Feb 19 01:15:57 emp01
>>>>> slapd[3297]: conn=2378 fd=48 TLS established tls_ssf=256
>>>>> ssf=256 Feb 19 01:15:57 emp01 slapd[3297]: conn=2378 op=1
>>>>> BIND dn="" method=128 Feb 19 01:15:57 emp01 slapd[3297]:
>>>>> conn=2378 op=1 RESULT tag=97 err=0 text= Feb 19 01:15:57
>>>>> emp01 slapd[3297]: conn=2378 op=2 SRCH
>>>>> base="dc=simonandkate,dc=lan" scope=2 deref=0
>>>>> filter="(objectClass=*)" Feb 19 01:15:57 emp01 slapd[3297]:
>>>>> conn=2378 op=2 SEARCH RESULT tag=101 err=0 nentries=44 text=
>>>>> Feb 19 01:15:57 emp01 slapd[3297]: conn=2378 op=3 UNBIND Feb
>>>>> 19 01:15:57 emp01 slapd[3297]: conn=2378 fd=48 closed
>>>>>
>>>>> Yet Horde can't START_TLS.
>>>>>
>>>>> The CA certificate file on the system is world readable - how
>>>>> does Horde find it?
>>>>
>>>> Is it installed to the default certificate store? For example,
>>>> under SUSE you put it in  /etc/ssl/certs and run
>>>>
>>>> c_rehash /etc/ssl/certs/
>>>>
>>>>
>>>> - -- Ralf Lang
>>>
>>> New cacert.pem is in two places, /etc/openldap/cacerts where
>>> openldap config files want it to be (ldap.conf, pam_ldap.conf,
>>> nslcd.conf), and in /etc/pki/tls/certs which is the system
>>> default for CentOS.
>>>
>>> Same places it was before...and I've run c_rehash.
>>>
>>> I'm assuming that for some reason the php ldap_start_tls function
>>> is failing which is what the Horde Ldap.php error is telling me.
>>>
>>> Just not sure why when a system ldapsearch call with no
>>> specified cacert location succeeds.
>>>
>>> I'm not a php programmer, but may have to see if I can try that
>>> command from php cli somehow. Or can you tell me what I can use
>>> in Horde's configuration PHP command line screen to test ldap
>>> tls?
>>>
>>> Simon -- Horde mailing list Frequently Asked Questions:
>>> http://horde.org/faq/ To unsubscribe, mail:
>>> horde-unsubscribe at lists.horde.org
>>
>> Got home this evening, prepared to jump in and start
>> troubleshooting... and it's working. :-O
>>
>> No idea why - something cached maybe?
>
> Did you restart the Apache or the server? I remember effects not
> happening at once too when I last had certificate troubles.
>
>
> - --
> Ralf Lang

I have a segfault trap that runs 24x7 and catches the occasional apc  
segfault, and that had restarted apache. I swear I had restarted it  
lst night though... Who knows, it was late... :-/

It appears that even though the cacert file was apache readable, it  
hadn't actually tried to read it again.

What it has done though is boost my knowledge of PHP and LDAP TLS.

I found the following script either executed as a standalone php script as is:

<?php
   $host = 'ldap.server';
   $port = 389;
   $user = 'cn=bindasuser,dc=ldapcontext,dc=lan';
   $pass = 'password in here';

   // Connect, set options and bind
   $ds = ldap_connect($host, $port);
   if (!ldap_set_option($ds, LDAP_OPT_PROTOCOL_VERSION, 3))  
exit('Could not disable referrals');
   if (!ldap_set_option($ds, LDAP_OPT_REFERRALS, 0)) exit('Could not  
disable referrals');
   if (!ldap_start_tls($ds)) exit('Could not start TLS');
   if (!ldap_bind($ds, $user, $pass)) exit('Bind operation failed');

   // A quick list operation to make sure it worked
   if (!$result = ldap_list($ds, 'dc=ldapcontext,dc=lan',  
'objectClass=*')) exit('List operation failed');
   print_r(ldap_get_entries($ds, $result));

Or run in Horde context on Horde PHP Shell page (dropping the opening  
php tag) works beautifully to test underlying PHP capability for LDAP  
connection over TLS, which rules out that it's a Horde problem...

Sorry for the noise. :-(

Simon

--
Simon Wilson
M: 0400 12 11 16
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: PGP Digital Signature
URL: <http://lists.horde.org/archives/horde/attachments/20130219/43191809/attachment.bin>