LDAP connection with TLS or SSL returns error.

[TafkaMax]

php bin/console ldap:sync -d -vvv
LDAP users and groups sync script for Gitlab-CE

[warning] Dry run enabled: No changes will be persisted.
[notice] Loading configuration.
[notice] Loaded configuration.
[notice] Validating configuration.
[warning] Configuration: ldap->server->port missing. (It will be determined by the encryption setting.)
[warning] Configuration: ldap->server->bindDn missing. (Assuming anonymous access.)
[warning] Configuration: gitlab->options->groupNamesToIgnore missing. (Assuming none.)
[warning] Configuration: gitlab->options->groupNamesOfExternal missing. (Assuming none.)
[notice] Validated configuration.
[notice] Retrieving directory users and groups.
Getting users and groups from LDAP...
[notice] Establishing LDAP connection.
[debug] LDAP: Enabling debug mode
[debug] LDAP: Connecting
[debug] LDAP: Setting options
[debug] LDAP: Binding
TLS: can't connect: (unknown error code).
[error] LDAP failure: Can't contact LDAP server. (Code -1)

I tried to see if I have certs:

openssl s_client -connect redacted:389 -starttls ldap -showcerts
openssl s_client -connect redacted:636 -showcerts

And I have certificates. Super weird issue. Currently running on port 389 and no encryption works for now.

[Adambean]

I can't really support this one directly as this tool simply leverages PHP's LDAP functionality directly. (This tool doesn't do any SSL/TLS function itself.) I can only offer you some suggestions:

• If you've compiled PHP yourself ensure that OpenSSL or SSPI was included.
• Check that your LDAP server is serving a modern enough version of TLS with a compatible cipher suite.
• If you're using a SSL/TLS certificate of which was not signed by a well known certificate authority ensure that the root CA is trusted in your operating system's trusted root certificate authority store. (Most likely issue.)
• I doubt self-signed certificates will work at all.

You may also want to test if your PHP is capable of SSL/TLS at all by running in a terminal:

php -r "print file_get_contents('https://www.example.com/');"

What return code did openssl give you without -showcerts? E.g. for my LDAP server I get:

$ openssl s_client -connect server.example.net:636 </dev/null
CONNECTED(00000004)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = server.example.net
verify return:1

[TafkaMax]

Hi, wow thanks for the quick response!

Checking if I have openssl enabled.

php -i | grep -i openssl
openssl
OpenSSL support => enabled
OpenSSL Library Version => OpenSSL 3.0.11 19 Sep 2023
OpenSSL Header Version => OpenSSL 3.0.9 30 May 2023
Openssl default config => /usr/lib/ssl/openssl.cnf
openssl.cafile => no value => no value
openssl.capath => no value => no value
Native OpenSSL support => enabled

The php script for example was OK. I got the contents.

CONNECTED(00000003)
depth=2 C = REDACTED
verify return:1
depth=1 C = REDACTED
verify return:1
depth=0 C = REDACTED
verify return:1

I am using a well-known CA whose certs are in /etc/ssl/certs via apt pkgs.

After the certificates chain I got.

subject=C = REDACTED
issuer=C = REDACTED
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 5830 bytes and written 399 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 4096 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
DONE

[TafkaMax]

Running this on Debian 12.

[Adambean]

I get code 4 instead of 3 for the "CONNECTED" line though I'm not sure what the difference is. The rest of the response looks quite the same.

Did the PHP file_get_contents HTTPS test work?

Which version of PHP are you running? I forget what Debian ships as standard as I've been using the Sury repository to get a multi-version environment for quite a few years. (I've got this tool running on Windows 11 and Debian 12 currently.)

I guess your LDAP server isn't configured (intentionally or default) to mandate that client-side certificates are required for SSL/TLS communications? (Two way verification.)

This tool is using PHP's native LDAP functions therefore there's little more I can suggest:

• Implicit SSL/TLS is handled here
• Explicit SSL/TLS (STARTTLS) is handed here

You may get some useful output if you also enable LDAP debugging in your config.yml file. Otherwise removing the @ prior to the ldap_* functions in the code linked above may also provide you with more verbose output.

[TafkaMax]

Thanks for the feedback I will check it out!

[TafkaMax]

I get code 4 instead of 3 for the "CONNECTED" line though I'm not sure what the difference is. The rest of the response looks quite the same.

Did the PHP file_get_contents HTTPS test work?

Which version of PHP are you running? I forget what Debian ships as standard as I've been using the Sury repository to get a multi-version environment for quite a few years. (I've got this tool running on Windows 11 and Debian 12 currently.)

I guess your LDAP server isn't configured (intentionally or default) to mandate that client-side certificates are required for SSL/TLS communications? (Two way verification.)

This tool is using PHP's native LDAP functions therefore there's little more I can suggest:

* [Implicit SSL/TLS is handled here](https://github.com/Adambean/gitlab-ce-ldap-sync/blob/fab2ace0071f12b95735baaa30bf141ce0226ff3/src/LdapSyncCommand.php#L850-L855)

* [Explicit SSL/TLS (STARTTLS) is handed here](https://github.com/Adambean/gitlab-ce-ldap-sync/blob/fab2ace0071f12b95735baaa30bf141ce0226ff3/src/LdapSyncCommand.php#L880-L885)

You may get some useful output if you also enable LDAP debugging in your config.yml file. Otherwise removing the @ prior to the ldap_* functions in the code linked above may also provide you with more verbose output.

The output of the php_contents seems OK.

php -r "print file_get_contents('https://www.example.com/');"
<!doctype html>
<html>
<head>
    <title>Example Domain</title>

    <meta charset="utf-8" />
    <meta http-equiv="Content-type" content="text/html; charset=utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1" />
    <style type="text/css">
    body {
        background-color: #f0f0f2;
        margin: 0;
        padding: 0;
        font-family: -apple-system, system-ui, BlinkMacSystemFont, "Segoe UI", "Open Sans", "Helvetica Neue", Helvetica, Arial, sans-serif;

    }
    div {
        width: 600px;
        margin: 5em auto;
        padding: 2em;
        background-color: #fdfdff;
        border-radius: 0.5em;
        box-shadow: 2px 3px 7px 2px rgba(0,0,0,0.02);
    }
    a:link, a:visited {
        color: #38488f;
        text-decoration: none;
    }
    @media (max-width: 700px) {
        div {
            margin: 0 auto;
            width: auto;
        }
    }
    </style>    
</head>

<body>
<div>
    <h1>Example Domain</h1>
    <p>This domain is for use in illustrative examples in documents. You may use this
    domain in literature without prior coordination or asking for permission.</p>
    <p><a href="https://www.iana.org/domains/example">More information...</a></p>
</div>
</body>
</html>

---

The PHP version shipped in Debian 12 is the following:

 php --version
PHP 8.2.7 (cli) (built: Jun  9 2023 19:37:27) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.2.7, Copyright (c) Zend Technologies
    with Zend OPcache v8.2.7, Copyright (c), by Zend Technologies

I will check the other options you sent me.

[TafkaMax]

Turns out I needed the libldap-common package from apt to be installed.

FIX: sudo apt install libldap-common

[Adambean]

Ah cool, thanks for sharing your solution.

I'd not noticed it as that package came with the openldap package on one of my Debian servers. For the other using 389-DS another utility package must have fulfilled the same role.