Todo #9417
closedConvert LDAP TLS setup from environment to LDAP_OPT_X_TLS_* set options
Added by Jim Pingle over 5 years ago. Updated almost 4 years ago.
100%
Description
PHP 7.1 added support for configuring the LDAP CA/Cert environment directly, rather than relying on the environment variables. These use new constants named LDAP_OPT_X_TLS_<blah>
For example:
ldap_set_option($ldap, LDAP_OPT_X_TLS_CERTFILE, "{$cert_prefix}.crt");
The use of environment variables may also be contributing to occasional failures of Diagnostics > Authentication testing LDAP logins with/without SSL.
Updated by Jim Pingle over 5 years ago
- Status changed from New to Feedback
- % Done changed from 0 to 100
Applied in changeset 996a1ad90e5682bf881bafd8b75d1b1a7e3f7831.
Updated by Jim Pingle over 5 years ago
See #9433 for an additional example of a problem case solved by this patch
Updated by Jim Pingle over 5 years ago
- Target version changed from 2.5.0 to 2.4.4-p3
Updated by Chris Linstruth over 5 years ago
2.4.4-p3
This all seems to work. It also seems much more consistent as posited in the description. I did a lot of bouncing around between SSL/636, STARTTLS, Clear, making changes to the server capabilities and requirements and everything seemed to happen as expected.
Much improved. Thank you.
Updated by Jim Pingle over 5 years ago
- Status changed from Resolved to New
- Target version changed from 2.4.4-p3 to 2.5.0
Upon further testing this does not appear to be working for self-signed certificates. It works for global, however. Will need to be backed out of 2.4.4 and revisited for 2.5.0, where it also doesn't appear to be working for this scenario.
Updated by Jim Pingle over 5 years ago
- Status changed from New to Feedback
Applied in changeset 2bf6d4322622765bd1ce6ca8915ff75890885566.
Updated by Jim Pingle over 5 years ago
It looks like LDAP_OPT_X_TLS_CACERTDIR and LDAP_OPT_X_TLS_CACERTFILE are being set but for some reason not honored as they should be. I can retrieve the set values with ldap_get_option()
, but the connection still fails to validate the CA even though the correct file is in place. Checking with the exact same CA file at the CLI using s_client shows the CA as valid.
There was a PHP bug filed a long time ago, but was closed for lack of feedback: https://bugs.php.net/bug.php?id=73558
A couple other similar posts around but nothing concrete either way.
Will keep testing on 2.5.0 but this may need backed out entirely, or at least reworked so the old style is only used for self-signed.
Updated by Jim Pingle over 5 years ago
- Category changed from User Manager / Privileges to Authentication
Updated by Jim Pingle about 5 years ago
- Target version changed from 2.5.0 to Future
Taking this off 2.5.0. I backed the changes out. It appears to be an upstream problem in PHP still, and no movement on the bug report above. I left a comment with some more details. We can revisit this in the future if the bug ever gets fixed.
Updated by Jim Pingle about 4 years ago
- Target version changed from Future to 2.5.0
And back on 2.5.0... Looks like there is some slightly different required syntax than I was using before. I can now use the new method and no longer see the unknown CA errors.
Commits coming.
Updated by Jim Pingle about 4 years ago
- Status changed from New to Feedback
Applied in changeset 39f48832cd45cc3a5f5f8d355bbd9253c7bcf7ae.
Updated by Jim Pingle about 4 years ago
This is working better but today I'm seeing some inconsistencies in the behavior. I can flip back and forth between testing two LDAP servers with different CAs and most of the time they both work, but some results return a failure. Packet capture shows that when it fails, it's an "unknown CA" error. So somehow it still appears to be confusing the LDAP environments.
The functions setting the values succeed, but there also doesn't seem to be any function which can read the values of the LDAP_OPT_X_TLS_CACERTDIR / LDAP_OPT_X_TLS_CACERTFILE variables since they use a NULL resource identifier.
Updated by Fernando Barros about 4 years ago
- File Screen Shot 2020-11-06 at 6.57.51 PM.png added
- File Screen Shot 2020-11-06 at 6.58.10 PM.png added
- File Screen Shot 2020-11-06 at 6.59.53 PM.png added
- File Screen Shot 2020-11-06 at 7.01.20 PM.png added
- File Screen Shot 2020-11-06 at 7.01.47 PM.png added
Updated by Jim Pingle about 4 years ago
- File deleted (
Screen Shot 2020-11-06 at 6.57.51 PM.png)
Updated by Jim Pingle about 4 years ago
- File deleted (
Screen Shot 2020-11-06 at 6.58.10 PM.png)
Updated by Jim Pingle about 4 years ago
- File deleted (
Screen Shot 2020-11-06 at 6.59.53 PM.png)
Updated by Jim Pingle about 4 years ago
- File deleted (
Screen Shot 2020-11-06 at 7.01.20 PM.png)
Updated by Jim Pingle about 4 years ago
- File deleted (
Screen Shot 2020-11-06 at 7.01.47 PM.png)
Updated by Renato Botelho almost 4 years ago
- Status changed from Feedback to Resolved
Marking it as resolved since nobody answered in 3 months