php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #48866 ldap.conf TLS_REQCERT directive fails for ldaps
Submitted: 2009-07-09 09:35 UTC Modified: 2013-02-18 00:33 UTC
Votes:36
Avg. Score:4.4 ± 0.9
Reproduced:28 of 31 (90.3%)
Same Version:16 (57.1%)
Same OS:20 (71.4%)
From: dev at lechat dot org Assigned: pajoye (profile)
Status: No Feedback Package: LDAP related
PHP Version: 5.3.0 OS: win32 only - windows server 2003
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: dev at lechat dot org
New email:
PHP Version: OS:

 

 [2009-07-09 09:35 UTC] dev at lechat dot org 
Description:
------------
Dealing with a secure ldap connection :
Since php 5.3, the
'TLS_REQCERT never' (means do not check certificate validity, and process the request anymore)
directive in C:\OpenLDAP\sysconf\ldap.conf are not applied when trying to bind an ldapS server that emit a certificate with an invalid CA.

The result is that the ldapS bind fails because php refuse the certificate.

By using a filMonitor program, I saw that since php 5.3 php_ldap.dll, the ldap conf file is now 'c:\ldap.conf' rather than C:\OpenLDAP\sysconf\ldap.conf. I tried to put directive in this file too. I can see that the file is open and read, but the directive 'TLS_REQCERT never' is not applied. Bind fails.


On the same server this is perfectly working with php < 5.3 (until 5.2.9-1 as fas as I know).

Note that standard ldap connection works as expected with 5.3

Reproduce code:
---------------
$ldapConnect = ldap_connect('ldaps://ldaps.myserver.com:3269');
ldap_set_option($ldapConnect, LDAP_OPT_PROTOCOL_VERSION, 3);
ldap_set_option($ldapConnect, LDAP_OPT_REFERRALS, 0);
$ldapBind = ldap_bind($ldapConnect, $username,$password);
$filter="(| (employeeid=$user)(name=$user)(cn=$user) (userprincipalname=$user@mydomain) ) ";
$ldapSearch = ldap_search($ldapConnect, $baseDn, $filter);
$ldapEntries = ldap_get_entries($ldapConnect, $ldapSearch);
ldap_free_result($ldapSearch);
ldap_unbind($ldapConnect);

Expected result:
----------------
ldap_get_entries returns ldap entries that match whith the filter, as expected.

Actual result:
--------------
None, cannot bind.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2009-08-05 21:59 UTC] jani@php.net 
Does this happen also with PHP 5.2.10 ?
 [2009-08-07 08:04 UTC] dev at lechat dot org 
Hi,
I didn't try 5.2.10.
I will make a try in one week
when i Will be back from holidays (-;
At this point I'll give you a feedback
if the problem occurs or not with 5.2.10.
 [2009-08-07 12:01 UTC] pajoye@php.net 
Has to be fixed in the ldap libs.
 [2009-08-31 15:26 UTC] jbd at anl dot gov 
I have found that moving ldap.conf to c:\ldap.conf and restarting the Windows machine (not just Apache) resolved the error for me with PHP 5.3 using LDAPS.
 [2009-09-02 11:17 UTC] dev at lechat dot org 
I have now tested with 5.2.10 and It works succesfully as with 5.2.9-1.

I retry with 5.3.0, to test jbd at anl dot gov advice about restart windows and not only apache, but I got the same problem. 
'TLS_REQCERT never' defined in c:\ldap.conf is not applied. I can still observe that this file is open and read with a filemonitor at the first ldaps request.

Hope this will be effectively fixed in next ldap lib version.

Thank you for your help.
 [2009-09-10 19:17 UTC] phpuser at mailinator dot com 
Same issue with Windows Server 2008 R2 and PHP 5.3.0 and 5.3.1 RC1.  Neither Placing the ldap.conf file in the normal directory nor C:\ and restarting the OS fixed the problem.  I now have the file located in both directories and it still refuses to work.
 [2009-09-11 12:58 UTC] phpuser at mailinator dot com 
Upon further investigation, I found that my install was looking for the ldap.conf file in the root of the D drive.  I'm guessing that is because I move my inetpub directory off of the system drive in all my installs.  Upon placing the ldap.conf file there, giving read permissions to the IIS_IUSRS group, and a reboot, it began working. This is on a Server 2008 R2 box with PHP 5.3.0 NTS VC9.
 [2009-09-15 13:13 UTC] gerrit dot lampe at t-online dot de 
referring to phpuser at mailinator dot com i can confirm, that the problem for me was solved, too by moving ldap.conf to root of the drive where inetpub is placed.

read permissons for IIS_IUSRS group or system reboot was not necessary in my case.

System:
Windows Server 2003 Enterprise Edition
Service Pack 2
IIS 6.0
PHP 5.3.0
 [2009-09-27 13:28 UTC] pajoye@php.net 
I have updated the OpenLdap libraries and the next 5.3 snapshots should work as expected, looking for the ldap.conf in the default directory, which is defined in c:\opendlad\sysconf.

The next snapshots should be online in ~1h from now. Please let me know if this change fixes the problem for your setups.
 [2009-10-05 01:00 UTC] php-bugs at lists dot php dot net 
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
 [2010-01-17 13:54 UTC] mailNO at SPAMgossimaniac dot net 
I have recently tested this with php 5.3.1 on Windows XP with Apache2.2 - it does not work :/ Though I was stepping back onto php5.2.12 where it runs smoothly. Could you recheck this? Thank you.
 [2010-01-17 14:02 UTC] pajoye@php.net 
Please try using this snapshot:

  http://snaps.php.net/php5.3-latest.tar.gz
 
For Windows:

  http://windows.php.net/snapshots/
 [2010-01-17 14:16 UTC] pajoye@php.net 
The library has been updated after 5.3.1.
 [2010-01-24 02:01 UTC] giselebrugger at gmail dot com 
I changed

C:\OpenLDAP\sysconf\ldap.conf to 

c:\ldap.conf
and restart windows 2008 
Now, its ok ldap + ssl connection .

Thanks

I use : apache 2.2.14
        php 5.3.1
 [2010-01-25 01:00 UTC] php-bugs at lists dot php dot net 
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
 [2010-02-03 15:21 UTC] akatherder at hotmail dot com 
This bug still exists in PHP 5.3.1 for Windows/IIS.

There are no Windows binaries snapshots at http://windows.php.net/snapshots/

"5.3 has no release."
 [2010-04-28 10:45 UTC] dietrich dot m dot 3 at pg dot com 
No comments since more than 2 months ?
I do still have this issue. Any workarounds that I missed ?
the ldap.conf is not accepted in C:\ nor at C:\OpenLDAP\sysconf.

Using ProcessMonitor, I was not able to find any attempt to access a file named ldap.conf...
 [2010-04-28 10:52 UTC] dietrich dot m dot 3 at pg dot com 
correction to my last comment: placing the ldap.conf into the root folder of the drive where my Apache Installation is located did work.
Note: HTROOT is on another drive. It might be bound to Server_Root ??
 [2010-04-28 10:55 UTC] pajoye@php.net
-Status: No Feedback +Status: Assigned
 [2010-04-28 10:55 UTC] pajoye@php.net 
Yes, the bug is not in php itself but in the build of the ldap libraries. It will be fixed in the next release (5.3.3) while being available in the snapshots (I'm working on restoring them as well).

The trick is to put it in the root of the current drive, not very clean but it can help to work around this problem.
 [2010-06-18 09:40 UTC] pajoye@php.net
-Status: Assigned +Status: Feedback
 [2010-06-18 09:40 UTC] pajoye@php.net 
Please try 5.3.3RC1
 [2010-11-10 16:53 UTC] tegwe002 at umn dot edu 
Based on other people's comments I did a little testing. Here's what I found out.

System:
PHP 5.3.3 Win32 vc6 x86
Windows server 2008 R2 Enterprise (no service pack)
Apache 2.2.15 

We too have our web-root (e) on a different drive than the system root (c). Since this machine is in production, I put one copy of the file in each location. I tried without reboot and had no joy.

After reboot I was able to connect to ldap over ssl with no errors. 

Then I did a little testing to see which file was being used. I tried moving the test script between the c: and e: drives. 

The file must be in the root of the drive that the script is run from. So if you run scripts from more than one drive you'll need to copy the file to the root of each drive.

I hope this helps someone else.
 [2011-01-27 12:10 UTC] julien dot moisan at agrostar dot fr 
Same trouble with PHP 5.3.0 with Windows

when i move ldap.conf to c:/ that's work fine.
 [2011-03-21 14:26 UTC] lorenz dot ulrich at phz dot ch 
In my Windows 7 machine with PHP 5.3.1, "TLS_REQCERT never" in a file "C:\ldap.conf" (was C:\openldap\sysconf\ldap.conf for PHP < 5.3) works fine for establishing StartTLS LDAP connections using port 389.
 [2011-03-28 21:00 UTC] ocala at udistrital dot edu dot co 
OS: Windows 7 64 Bit.
PHP Version 5.3.0
Apache Version 2.2.11
Blunded Like Wamp

Wamp installed in C:\wamp
Script running in G:\www\test.php

LDAP Configuration file in C:\ldap.conf

This settings allows a working ldaps:// connection to a Windows 2008 R2
 [2012-01-12 16:47 UTC] mo at dgi dot no 
Hello!

I'm still experiencing this issue in PHP 5.3.8 on IIS 7, Win 2008 R2. The most 
peculiar thing is that this issue also arises even though the server has installed 
the trusted root CA cert which have issued the LDAP-server cert. I also use the 
LDAP-servers FQDN which matches the cert. 

It strikes me as almost funny to have to disable cert-cheking on a cert i know is 
valid. Any one else been experiencing this?
 [2013-02-18 00:33 UTC] php-bugs at lists dot php dot net 
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Thu Nov 21 12:01:29 2024 UTC