Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1076249

Summary: Intermittent TLS certificate failures using php54-php-ldap
Product: Red Hat Software Collections Reporter: Ross Davis <molecularbear>
Component: phpAssignee: Remi Collet <rcollet>
Status: CLOSED INSUFFICIENT_DATA QA Contact: BaseOS QE - Apps <qe-baseos-apps>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: php54CC: jorton
Target Milestone: ---   
Target Release: 2.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-11-05 14:54:54 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
ldap debug output showing both bad and good connections none

Description Ross Davis 2014-03-13 21:59:00 UTC 
Created attachment 874170 [details]
ldap debug output showing both bad and good connections

Description of problem:

LDAP connects/binds via php-ldap work fine for a time on a lightly loaded httpd server. After serving requests for about 15 minutes, I will start to see these errors intermittently (from ldap debug output):

TLS: certificate [OU=Equifax Secure Certificate Authority,O=Equifax,C=US] is not valid - error -8172:Peer's certificate issuer has been marked as not trusted by the user..
TLS: error: connect - force handshake failure: errno 2 - moznss error -8172
TLS: can't connect: TLS error -8172:Peer's certificate issuer has been marked as not trusted by the user..
ldap_err2string
ldap_err2string

(see full output in attachment)

From examining the logs, it looks like at least one httpd child gets "corrupted" in some way and forgets how to validate the certificate, while the other httpd children continue to connect to ldap with no issue.

This problem is *VERY* similar to this report: https://bugzilla.redhat.com/show_bug.cgi?id=767832 but my understanding is that the underlying problem from #767832 is resolved in my versions of the software.

Version-Release number of selected component (if applicable):

curl-7.19.7-37.el6_4.x86_64 (just in case related to bug #767832)
httpd-2.2.15-29.el6_4.x86_64
openldap-2.4.23-32.el6_4.1.x86_64
php54-php-ldap-5.4.16-7.el6.1.x86_64

How reproducible:

Occurs after about 15 minutes of light web traffic. Running from the command line works fine.

Steps to Reproduce:

1. Tell PHP developer to set `ldap_set_option(NULL, LDAP_OPT_DEBUG_LEVEL, 7);` so you can see what's going on
2. Serve light web traffic for about 15 minutes with PHP scripts to connect to ldap
3. Notice messages in error log (TLS error -8172:Peer's certificate issuer has been marked as not trusted by the user)

Actual results:

After about 15 minutes, requests served by one or more httpd children start erroring with 8172:Peer's certificate issuer has been marked as not trusted by the user

Expected results:

The certificate should be correctly verified regardless of which httpd process is serving the request.

Additional info:

Problem goes away if httpd config has MaxRequestsPerChild=1, validating the theory that an httpd process needs to serve multiple requests before getting itself in a "corrupted" state.

I will *always* get the error if I do not have this environment variable set: LDAPTLS_CACERTDIR=/etc/openldap/certs

This will fail on the command line:

php ldap_test.php

But this works every time:

LDAPTLS_CACERTDIR=/etc/openldap/certs php ldap_test.php

And so I set this config for apache in `/etc/sysconfig/httpd`:

export LDAPTLS_CACERTDIR=/etc/openldap/certs

I initially thought maybe an httpd process was "forgetting" that config, but debugging showed me that the environment variable is still set even when the error occurs.
Comment 2 Joe Orton 2014-03-14 14:05:37 UTC 
Thanks for the report.   I notice you are using 6.4 packages - if you are able to validate the bug on a 6.5 machine that might be helpful.  I cannot see anything pertinent in changes to openldap etc since 6.4 which might affect this, so this is a long shot.
Comment 6 Ross Davis 2014-03-25 16:07:31 UTC 
I appreciate the response. I was not able to procure the time/resources to try this out on 6.5, but we did find a workaround. Instead of doing the following in `/etc/sysconfig/httpd`:

export LDAPTLS_CACERTDIR=/etc/openldap/certs

We are now doing this:

export LDAPTLS_REQCERT=never

That setting appears to "stick", unlike the former. It's certainly not ideal to bypass the certificate check, but pretty minimal risk for my circumstances.
Comment 7 Joe Orton 2014-11-05 14:54:54 UTC 
Since we don't have a reliable reproduction recipe for this issue, and you have a workaround, I'm going to close this out.  If you have further issues please feel free to contact Red Hat Support.
Comment 8 Ross Davis 2015-11-18 14:39:33 UTC 
After experiencing this problem with updated software (REHL 6.7, php55, httpd24, openldap-2.4.40-6) I reinvestigated and finally figured it out.

Our admins had changed the base config in `/etc/openldap/ldap.conf` to:

1) change TLS_CACERTDIR to a custom directory
2) add TLS_CACERT to point to a PEM file in said custom directory

My apache startup config was effectively reverting (1) back to the stock openldap config - which is what I wanted.

HOWEVER, it turns out I also needed to revert (2) back to stock config for this thing to not get its wires crossed.

My `/opt/rh/httpd24/root/etc/sysconfig/httpd` now looks like this:

export LDAPTLS_CACERTDIR=/etc/openldap/certs
export LDAPTLS_CACERT=/etc/pki/tls/cert.pem

My best guess is that there is some scenario where openldap was choosing to use the bad CACERT rather than the good CACERTDIR. By making them both "good", the cert check works regardless of which one it chooses.