How do I solve ldap_start_tls() “Unable to start TLS: Connect error” in PHP?

Question

I'm getting:

Warning: ldap_start_tls() [function.ldap-start-tls]: Unable to start TLS: Connect error in /var/www/X.php on line Y

/etc/ldap/ldap.conf:

TLS_CACERT     /etc/ssl/certs/ca.crt

ca.crt is the CA which signed the LDAP server certificate. The certificate on the LDAP server is expired and I can't change it.

Answer 1

You can ignore the validity in windows by issuing

putenv('LDAPTLS_REQCERT=never');

in your php code. In *nix you need to edit your /etc/ldap.conf to contain

TLS_REQCERT never

Another thing to be aware of is that it requires version 3 (version 2 is php default):

//$hostnameSSL example would be "ldaps://just.example.com:636" , just make sure it has ldaps://
$con = ldap_connect($hostnameSSL);
ldap_set_option($con, LDAP_OPT_PROTOCOL_VERSION, 3);

To get a better idea of what's going on, you can enable debug logging by:

ldap_set_option(NULL, LDAP_OPT_DEBUG_LEVEL, 7);

This can be done before the ldap_connect takes place.

Answer 2

My solution/workaround is to use

/etc/ldap/ldap.conf:
#TLS_CACERT /etc/ssl/certs/ca.crt
TLS_REQCERT never

If you have any better idea, please post another answer.

Answer 3

The specific scenario presented in the question--with an expired certificate that can't be changed--does appear to require disabling certificate validation on the LDAP client.

However , I suspect a lot of people, like me, reach this page for other root causes of receiving opaque LDAP TLS errors, where disabling validation of TLS certificates is not an appropriate answer.

In my case--using the LDAP Authentication extension for Mediawiki on an Ubuntu 18.04 LTS server, and authenticating against Active Directory on a Windows Server 2012 server--authentication stopped working in January/February 2020. The server certificate and the CA certificate were still both valid, and openssl s_client -verify 2 -connect <AD server>:636 from the Mediawiki server passed just fine.

Eventually I noticed that the signature algorithm in the SSL certificate served by AD/LDAP was SHA1, which I remembered recently suffered from the first known chosen-prefix collision exploit . This led me to investigate the changelog for packages that had recently been updated on the system, which turned up "Mark SHA1 as insecure for certificate signing" in the gnutls28 changelog circa January 8th, 2020 . (The chain of dependencies from the php-ldap package in Ubuntu 18.04 goes to php7.2-ldap -> libldap-2.4-2 -> libgnutls30, whose source package is gnutls28.)

I followed some instructions to update the Windows CA to use SHA256 and then selectively followed instructions to renew the AD/LDAP cert , installed the new CA cert on my Mediawiki server, and the problem was solved! Briefly, these steps included:

1. In an Admin PowerShell on the AD server, run certutil -setreg ca\\csp\\CNGHashAlgorithm SHA256
2. In the Certification Authority MMC, right click on the CA -> All Tasks -> Renew CA Certificate
3. In a blank MMC, add snap-in for Certificates; select Local Computer
4. Under Personal -> Certificates, find the current entry used by LDAPS (Kerberos Authentication template type) -> All Tasks -> Advanced Options -> Renew This Certificate with the Same Key
5. In the same window, open the new CA certificate -> Details -> Copy to file -> no private key -> base64-encoded X.509
6. Copy the resulting file to /usr/share/ca-certificates/ on the Mediawiki server, then run sudo dpkg-reconfigure ca-certificates and select the new CA cert for inclusion.

PS For SEO purposes, depending on the mode I was using, error messages included:

• ldap_start_tls(): Unable to start TLS: Connect error in /var/www/mediawiki/extensions/LdapAuthentication/LdapAuthenticationPlugin.php in the HTTP error log
• ldap_start_tls(): Unable to start TLS: Can't contact LDAP server in [...]
• Failed to start TLS. in the Mediawiki debug log (when using wgLDAPEncryptionType = ssl , ie encrypted LDAP port, 636)
• Failed to bind as CN=foobar,CN=Users,DC=myOrgName,DC=local in the Mediwiki debug log (when using wgLDAPEncryptionType = tls , ie STARTTLS on the unencrypted LDAP port, 389)

Answer 4

The path for ldap.conf in Windows is fixed:

c:\\openldap\\sysconf\\ldap.conf

A restart of the web server may be required to apply changes.

Answer 5

1. In debian based systems:

   Install the package: ldap-utils and in the file /etc/ldap/ldap.conf , edit the line:

    TLS_CACERT /etc/ldap/cacerts/cacert.asc

   Create the directory /etc/ldap/cacerts and copy the cacert to /etc/ldap/cacerts/cacert.asc

   Restart apache .

2. In redhat based systems:

   Install the package: openldap-clients and in the file /etc/openldap/ldap.conf edit the line:

    TLS_CACERT /etc/openldap/cacerts/cacert.asc

   Create the directory /etc/openldap/cacerts and copy the cacert to /etc/openldap/cacerts/cacert.asc

   Restart httpd

Answer 6

Some additional help for others, the certificate solution here solved my ldapsearch command line issue, but still PHP complained **Can't contact LDAP server**

Turned out to be SELinux on RHEL7 ( CentOS7 ) blocks HTTPD from using LDAP ports 389 and 636 by default, you can unblock with:

setsebool -P httpd_can_network_connect 1

Check your SELinux audit log file for things being blocked.

Answer 7

I was able to get this working properly with openldap on Amazon Linux (Elastic Beanstalk PHP 7.0) with MacOS Server 5 LDAP, with TLS set to demand.

in /etc/openldap/ldap.conf:

TLS_REQCERT demand

TLS_CACERT /etc/openldap/certs/yourcacert.pem

(note that if you are not using openldap, the path will be /etc/ldap/certs/yourcacert.pem). This setup did not work until I placed the certificate inside the certs folder; it did not work from any other path.

The certificate to be placed in that path is NOT the TLS certificate of the server. It is the CA (Certificate Authority) certificate of the authority whom issued the server/domain specific TLS certificate. Only the CA certificate placed in that path will allow TLS to work before attempting an LDAP bind in php. Get the CA certificate from your server or download it from the authority's site, they are freely available.

To test if LDAP bind is even working without TLS, set TLS_REQCERT never temporarily (may need to comment # out TLS_CACERT). If you get "Can't connect to LDAP" it is not a TLS error; it simply cannot connect to the server and you likely need to open port 389 (not 636 for TLS).

Remember to restart your Apache server every time you make a change to the config file or certificate.