pileup
pileup

Reputation: 3262

Can't contact LDAP server - unable to get local issuer certificate

I am trying to connect to the LDAP server with Laravel-Adldap2. The same config works on another server and on local machine.

I am using secured LDAPS connection (port 636).

But on one of the test servers, I get:

Can't contact LDAP server.

I have LDAP_USE_TLS=false and LDAP_USE_SSL=true in my .env file.

To further debug that, I made a vanilla PHP LDAP connection script:

<?php
ini_set('display_errors', 1);
error_reporting(E_ALL);
ldap_set_option(NULL, LDAP_OPT_DEBUG_LEVEL, 7);
putenv('LDAPTLS_REQCERT=never');
// using ldap bind
$ldaprdn  = 'uname';     // ldap rdn or dn
$ldappass = 'password';  // associated password    

$ldapconn = ldap_connect("ldaps://ldap.example.com:636")
    or die("Could not connect to LDAP server.");

if ($ldapconn) {   
  
    $ldapbind = ldap_bind($ldapconn, $ldaprdn, $ldappass);
        
    if ($ldapbind) {
        echo "LDAP bind successful...";
    } else {
        echo "LDAP bind failed...";
    }

}

?>

and I get:

TLS certificate verification: Error, unable to get local issuer certificate.
TLS trace: SSL3 alert write:fatal:unknown CA
TLS trace: error in error
TLS: can't connect: error:16000069:STORE routines:unregistered scheme.
ldap_err2string
PHP Warning: ldap_bind(): Unable to bind to server: Can't contact LDAP server

Now I am not sure if the error I get from the vanilla PHP script is related to the Adldap2 error, because maybe putenv('LDAPTLS_REQCERT=never'); doesn't work like LDAP_USE_TLS=false? So I am not sure what exactly cause the Adldap2 error and what causes the vanilla PHP script error, but I know that the same credentials work on other servers.

How can I debug this further? (I don't want to use TLS but I do want SSL - how can I be sure I do that with the vanilla PHP script?)

Upvotes: 0

Views: 6438

Answers (1)

Sammitch
Sammitch

Reputation: 32232

TLS and SSL generally refer to the same thing, but in the case of LDAP config the difference is where in the connection setup TLS is initiated.

For LDAP_USE_SSL [aka LDAPS] the the connection itself is started with TLS, and for LDAP_USE_TLS the connection starts in the plain, and then the STARTTLS command is used inside the transaction and then encrypted communication begins.

The error you're getting refers to the general-case TLS, and the problem is that the certificate that the server is presenting does not have a validation path to a trusted root certificate. Some common causes of this would be:

  1. The server is using a self-signed certificate.
  2. The server is not providing intermediate certificates.
  3. The server is using a certificate signed by an unknown authority, eg: an internal CA.
  4. The client machine's root CA bundle is outdated.

And solutions to these are:

  1. ldap_set_option($ldapconn, LDAP_OPT_X_TLS_REQUIRE_CERT, 0); but only do this if you know that the certificate is self-signed and you can't convince the server admin to use a properly-signed cert. This is the nuclear option and simply disables certificate validation. This is an "easy fix" for a lot of TLS issues, but it's also the least preferable as it just blindly trusts any certificate and has no protection against spoofing, MITM, etc.
  2. Ideally, talk to the server admin and get them to configure the LDAP server to serve the proper intermediate certs. But if they're intransigent about it you can include it yourself via: ldap_set_option($ldapconn, LDAP_OPT_X_TLS_CACERTFILE, "/path/to/intermediate.pem");
  3. You may or may not want to add the CA's root cert to the OS's certificate store. This would allow anything running on the server to properly validate that CA's certs. Otherwise, use same code as above, but the certificate file should be the root CA cert.
  4. Check your OS docs, but most linux distributions have a package like ca-certificates that you need to update.

Upvotes: 0

Related Questions