I have a working config on a machine I'll call prod-test. Talks TLS to my OpenLDAP provider. Built manually on a development CentOS 7.7 rig, I can log in to my wiki, make edits, monkey around. Seems to work great so far.
Once I had a working config in dev, I made a clone of our production wiki (it's a VM). It's a Mediawiki VM appliance/OVA, a default build pretty much straight from the foundation web page. Debian based. Changed the IP on my clone, updated my LocalSettings.php to match my prod-test build, added the LDAP extensions I have in my working build to my cloned appliance via SCP, gave it a php maintenance/update.php, copied/pasted the relevant portions of my LocalSettings.php over from my prod-test build, and kicked the tires. Started fine, page renders as expected, Special Pages:Version shows all my LDAP extensions, looking good... Attempted to login via LDAP with the production clone running my prod-test configs, I get the following:
<snip>
Warning: ldap_start_tls(): Unable to start TLS: Connect error in /var/www/mediawiki/extensions/LDAPProvider/src/PlatformFunctionWrapper.php on line 121
[4bdbee442bdc5006ac0c4d20] /index.php/Special:PluggableAuthLogin MWException from line 129 of /var/www/mediawiki/extensions/LDAPProvider/src/Client.php: Could not start TLS!
</snip>
Sigh... This extension is going to be the end of me.
Checked paths of certs to make sure I'm apples-to-apples in my tests ( both at /var/www/html/certs as I get real hairy about where PHP has permissions to access, can confirm this directory exists and is correct in LocalSettings.php), checked permissions on cert files (all owned by apache2/httpd user). Error isn't showing me "Can't find constant..." as it has in the past with permissions issues. Don't suspect permissions issues here.
On my OpenLDAP provider, the slapd.log shows me a connection attempt from my cloned production instance where I can see it starts TLS and then exits. Relevant entries look like this:
2019-11-21T21:25:55.878771+00:00 awesome.ldap.server slapd[248590]: conn=1513 fd=25 ACCEPT from IP=10.1.2.219:34524 (IP=0.0.0.0:389)
2019-11-21T21:25:55.878805+00:00 awesome.ldap.server slapd[248590]: connection_get(25) 2019-11-21T21:25:55.878841+00:00 awesome.ldap.server slapd[248590]: conn=1513 op=0 EXT oid=1.3.6.1.4.1.1466.20037 2019-11-21T21:25:55.878845+00:00 awesome.ldap.server slapd[248590]: do_extended: oid=1.3.6.1.4.1.1466.20037 2019-11-21T21:25:55.878859+00:00 awesome.ldap.server slapd[248590]: conn=1513 op=0 STARTTLS 2019-11-21T21:25:55.878883+00:00 awesome.ldap.server slapd[248590]: conn=1513 op=0 RESULT oid= err=0 text= 2019-11-21T21:25:55.887117+00:00 awesome.ldap.server slapd[248590]: daemon: activity on 1 descriptor 2019-11-21T21:25:55.887121+00:00 awesome.ldap.server slapd[248590]: daemon: activity on: 2019-11-21T21:25:55.887852+00:00 awesome.ldap.server slapd[248590]: daemon: read active on 25 2019-11-21T21:25:55.887875+00:00 awesome.ldap.server slapd[248590]: connection_get(25) 2019-11-21T21:25:55.888653+00:00 awesome.ldap.server slapd[248590]: conn=1513 fd=25 TLS established tls_ssf=256 ssf=256 2019-11-21T21:25:55.899089+00:00 awesome.ldap.server slapd[248590]: daemon: read active on 25 2019-11-21T21:25:55.899117+00:00 awesome.ldap.server slapd[248590]: connection_get(25) 2019-11-21T21:25:55.899137+00:00 awesome.ldap.server slapd[248590]: connection_read(25): input error=-2 id=1513, closing. 2019-11-21T21:25:55.899141+00:00 awesome.ldap.server slapd[248590]: connection_closing: readying conn=1513 sd=25 for close 2019-11-21T21:25:55.899158+00:00 awesome.ldap.server slapd[248590]: daemon: removing 25 2019-11-21T21:25:55.899196+00:00 awesome.ldap.server slapd[248590]: conn=1513 fd=25 closed (connection lost)
@ 888653, I can see the TLS connection is established. Quick check of what a -2 error is, looks like it's not presenting my client certificate. I have SCP'd my certs over from my working instance so I know they're formatted correctly and are valid certs. The TLS session *IS* getting established, but not progressing. Again, my LDAP settings are a lift from a known working build. confirmed it's a direct copy. Not sure why this started now.
running php maintenance/CheckLogin.php shows same fault as above.
On a whim, because we're moving our VM environment into more containerized world (docker), I went ahead and pulled the Mediawiki docker image from docker hub and wrote a compose file to support this. had to install php-ldap onto the image. Using the same LocalSettings.php file, updated appropriate mounts/volumes, put certs in the right places, and fired it up.
Same exact symptom.
So in summary...
Dev centOS build - LDAP works, can authenticate.
MediaWiki OVA appliance (Debian) - LDAP doesn't work, TLS can't connect. Same relevant settings in LocalSettings.php
Docker MediaWiki container - LDAP doesn't work, TLS can't connect. Same relevant settings in LocalSettings.php
To my mind, the only delta that I can obviously see is CentOS vs. Debian. But I don't think operating system issues make sense to my problem. What does make more sense might be php, specifically, php-ldap. I find it aggravating beyond compare that the OVA doesn't ship with LDAP "bones" already in it (like this wonderful extension and it's friends that make up LDAP hub should already be packed into it and turned off, AND the appropriate PHP LDAP modules included with the OS). I think I may be missing PHP modules with the builds that come from the foundations.
To you folks who work in Debian and have a working model of this, specifically what PHP modules do you have installed? would anyone with a working LDAP/Debian build mediawiki mind giving me a dump of their packages "apt list | grep php" ?
Any other bonus thoughts in troubleshooting here are most appreciated. And @Osnard, thank you for all you do to help this community. YTMND.