Description:
------------
While testing with binding to LDAP sources using SSL, it goes through all the certificates like the command line, but gets increasingly slower for each one.  With 65 certificates installed, it takes 39 seconds to go through it.  The command line OpenLDAP utilities, while going through the same certificate search, do not slow down.

Reproduce code:
---------------
<?php

ldap_set_option(NULL, LDAP_OPT_DEBUG_LEVEL, 7);
$conn = ldap_connect("ldaps://<ldap server>");
ldap_set_option($conn, LDAP_OPT_PROTOCOL_VERSION, 3);
ldap_bind($conn, "<dn>", "<password>");

?>

Expected result:
----------------
It should finish very quickly.

Actual result:
--------------
$ time php ./test-ldap.php
ldap_create
ldap_url_parse_ext(ldaps://<ldap server>)
ldap_bind_s
ldap_simple_bind_s
ldap_sasl_bind_s
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection
ldap_int_open_connection
ldap_connect_to_host: TCP <ldap server>:636
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying <numeric ldap server>:636
ldap_connect_timeout: fd: 3 tm: -1 async: 0
ldap_ndelay_on: 3
ldap_is_sock_ready: 3
ldap_ndelay_off: 3
ldap_int_sasl_open: host=<ldap server>
TLS certificate verification: depth: 0, err: 0, subject: <ldap server certificate info>
ldap_open_defconn: successful
ldap_send_server_request
ldap_result msgid 1
ldap_chkResponseList for msgid=1, all=1
ldap_chkResponseList returns NULL
wait4msg (infinite timeout), msgid 1
wait4msg continue, msgid 1, all 1
** Connections:
* host: <ldap server>  port: 636  (default)
  refcnt: 2  status: Connected
  last used: Wed Dec 13 15:22:12 2006

** Outstanding Requests:
 * msgid 1,  origid 1, status InProgress
   outstanding referrals 0, parent count 0
** Response Queue:
   Empty
ldap_chkResponseList for msgid=1, all=1
ldap_chkResponseList returns NULL
ldap_int_select
read1msg: msgid 1, all 1
ldap_read: message type bind msgid 1, original id 1
new result:  res_errno: 0, res_error: <>, res_matched: <>
read1msg:  0 new referrals
read1msg:  mark request completed, id = 1
request 1 done
res_errno: 0, res_error: <>, res_matched: <>
ldap_free_request (origid 1, msgid 1)
ldap_free_connection
ldap_free_connection: refcnt 1
ldap_parse_result
ldap_msgfree

ldap_free_connection
ldap_send_unbind
ldap_free_connection: actually freed

real    0m38.939s
user    0m36.746s
sys     0m0.216s

Now for the command line doing a bind AND a search to the exact same system, parameters, etc.:
$ time ldapsearch -x -H "ldaps://<ldap server>" -D "<dn>" -w "<password>" -b "<basedn>" -P 3 "(uid=<same user>)"
# extended LDIF
#
# LDAPv3
# base <basedn> with scope subtree
# filter: (uid=<same user>)
# requesting: ALL
#

<expected search record>

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

real    0m0.345s
user    0m0.096s
sys     0m0.044s

When I run strace on the php version, it drastically slows down on accessing the SSL certificates portion (ldap_int_sasl_open on the LDAP debug), with the CPU chugging at 100%.  The strace shows no system function causing a delay, just an increasing pause between one munmap and the next stat64 call.

I see other people reporting the same bug that have been dismissed (35610, 36145) with "We only wrap around the openldap library and openssl. If those fail, it's not our problem.".  I'm hoping I've shown above that it appears PHP is failing, while neither OpenLDAP nor OpenSSL are (because the command line utility works fine).  I freely admit this is strange as I imagine PHP is calling the same functions, but something is going horribly wrong somewhere with PHP that is not with the command line utils.

My ulimit -a is:
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
max nice                        (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) unlimited
max locked memory       (kbytes, -l) unlimited
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) unlimited
max rt priority                 (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) unlimited
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

So should not be an open files issue (although I have tried bumping it to 8192).  The machine is not running out of memory.