How to Test LDAPS

Test LDAPS connectivity, certificate chains, hostnames, protocol versions, binds, and searches to isolate transport and directory configuration failures.

Type
Tutorial
Level
Intermediate
Technologies
LDAP, LDAPS, PKI
On this page

Understanding LDAPS: Protocols and Security

Lightweight Directory Access Protocol (LDAP) is the backbone protocol for accessing directory services. When securing LDAP traffic, two distinct protocols are available: LDAPS (LDAP over SSL/TLS) and LDAP with StartTLS. Per RFC 4513, these methods are not interchangeable or compatible. Misconfiguring a client to use StartTLS on LDAPS port 636 (or vice versa, expecting LDAPS on port 389) will always fail—the protocol negotiation mechanisms are different and bound to their respective ports.

  • LDAPS: Initiates SSL/TLS as soon as the TCP connection opens, exclusively using port 636. No StartTLS operation is performed; the entire protocol flow is encrypted from the start.
  • LDAP with StartTLS: Establishes a plaintext LDAP session on port 389, then explicitly issues the StartTLS operation to upgrade to TLS encryption. Only then are further operations secured.

It is essential to select the correct protocol and port based on server configuration. Most legacy environments (especially older Active Directory) require LDAPS on port 636. Modern best practice—endorsed in RFC 4513—is to favor StartTLS, but LDAPS persists for backward compatibility and interoperability.

Common misconception: LDAPS and StartTLS are not cross-compatible. Attempting a StartTLS operation on port 636 will result in immediate protocol failure, and connecting to port 389 expecting LDAPS (immediate TLS handshake) will not succeed.

Prerequisites: What Must Be in Place Before Testing LDAPS

A robust LDAPS connection requires all of the following:

  • Directory server with a valid SSL/TLS certificate: The server must present a certificate signed by a Certificate Authority (CA) trusted by the client. According to industry standards and RFC 4513, this certificate must include a Subject Alternative Name (SAN) that exactly matches the server's hostname or fully qualified domain name as used by clients; use of only the Common Name (CN) is insufficient for modern clients.
  • Network accessibility to port 636: Firewalls and host-based protections should permit inbound connections to TCP port 636 on the directory server.
  • CA trust on the client: The client must have the issuing CA (and any intermediates) installed and trusted. If not, the TLS handshake will always fail, even with a technically valid certificate.
  • Server configuration: The LDAP server must be configured to both listen on port 636 and to use the correct certificate for LDAPS.

How to check these prerequisites:

  • Confirm the server is listening on port 636:

    • On Windows:
      Use PowerShell on the server:
      Get-NetTCPConnection -LocalPort 636
      Or:
      netstat -an | findstr 636
    • On Linux/Unix:
      netstat -tnlp | grep :636
      Output should indicate the LDAP daemon (e.g., slapd) is bound to port 636.

  • Verify open network path to port 636: From a client,

    • On Windows:
      Test-NetConnection -ComputerName "ldap.example.com" -Port 636
      If the result shows TcpTestSucceeded : True, port 636 is reachable.
    • On Linux/Unix:
      nc -vz ldap.example.com 636
      If successful, you'll see succeeded!; otherwise, connection errors.

  • Confirm certificate details: Examine the server's LDAPS certificate to ensure a SAN (Subject Alternative Name) exists and matches exactly the client-used server name.

Only after these prerequisites are verified is it meaningful to proceed with protocol-level LDAPS testing.

Testing LDAPS Connectivity: Step-by-Step on Windows and Linux

Testing with ldp.exe (Windows)

ldp.exe is a Microsoft-provided GUI utility for interacting directly with LDAP and LDAPS endpoints on Windows.

How to test LDAPS with ldp.exe:

  1. Start ldp.exe (from the Start menu or Run dialog).
  2. In the menu, select Connection > Connect.
  3. Enter the server name (e.g., ldap.example.com), set Port to 636, and check the SSL box.
  4. Click OK to connect.

Expected outputs:

  • Success:
    Established connection to ldap.example.com.
Returning LDAP result code: 0 (Success)
    Server information and supported controls are displayed in the log pane.
  • Common certificate error:
    Error: Cannot open connection. 
Error: <0x51>: Fail to connect to ldap.example.com.
    Further details (often about trust chain or certificate validation) may appear in the details pane.
  1. After connecting, from Connection > Bind, enter user credentials and perform a bind operation. A successful bind confirms both SSL/TLS handshake and authentication are functional.

Bind results:

  • Bind successful:
    Authenticated as DN 'CN=binduser,DC=example,DC=com'
  • Bind failure (protocol or certificate):
    Error: Cannot bind. 
Error: <0x31>: Invalid credentials
    or, for certificate issues,
    Error: <0x51>: LDAP_LOCAL_ERROR

Testing LDAPS with PowerShell (Windows)

PowerShell is a versatile environment for network and protocol checks, but with important limitations for LDAPS validation.

Check network connectivity (is port 636 reachable):

text
Test-NetConnection -ComputerName "ldap.example.com" -Port 636

Interpretation:

  • If TcpTestSucceeded : True, the server's port 636 is reachable from the client.
  • If TcpTestSucceeded : False, there is a network, DNS, or firewall issue; do not proceed to further protocol testing until resolved.

Limitation:
This check only confirms if the port is open. It does not prove that LDAPS service is running, or that SSL/TLS is configured correctly. No client/server handshake or certificate check occurs.

To test the SSL/TLS handshake (and validate the certificate): PowerShell alone does not provide a native command for this; use ldp.exe or a tool like openssl s_client for full handshake validation.

Testing with ldapsearch (Linux/Unix)

ldapsearch from OpenLDAP is the standard CLI tool for LDAP and LDAPS queries.

Basic LDAPS connectivity and bind test:

bash
ldapsearch -H ldaps://ldap.example.com:636 -D "cn=binduser,dc=example,dc=com" -W -b "dc=example,dc=com"
  • -H ldaps://ldap.example.com:636: Uses SSL/TLS immediately upon connection.
  • -D: Bind DN.
  • -W: Interactive password prompt for the bind user.
  • -b: Base DN for the search.

Certificate trust troubleshooting: If the server's certificate is signed by a private or non-standard CA, ensure the CA certificate is trusted by the client. You can set the environment variable LDAPTLS_CACERT to the path of your CA certificate:

bash
export LDAPTLS_CACERT=/etc/ssl/certs/my-ldap-ca.pem

On many Linux systems, you may also place the CA in /etc/ssl/certs/ and update the system's trusted store.

Expected outputs:

  • Success:
    # extended LDIF
#
# LDAPv3
# ...entries returned...
  • Certificate trust failure:
    ldapsearch: can't contact LDAP server (-1)
    additional info: TLS: hostname does not match CN in peer certificate
    or
    ldapsearch: Unable to start TLS: Server certificate verification failed: unable to get local issuer certificate
  • Network error (port/host unreachable):
    ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)

Note: The flag -ZZ (StartTLS) is not used with LDAPS URIs—per standards, it is only valid for LDAP connections on port 389.

Interpreting Results: Diagnosing Common LDAPS Errors

A methodical approach is required to translate tool outputs into actionable remediation steps.

Error Type: Certificate Problems

  • ldp.exe:
    Error: <0x51>: Fail to connect to ldap.example.com.
  • ldapsearch:
    ldapsearch: Unable to start TLS: Server certificate verification failed: unable to get local issuer certificate
    or
    TLS: hostname does not match CN in peer certificate
  • Root Cause: Server certificate missing SAN matching the server name OR client does not trust the CA.
  • Next Step:
    • Check that the server certificate SAN matches exactly the FQDN used by the client.
    • Ensure the CA certificate is present and trusted on the client (update LDAPTLS_CACERT, import CA as needed).

Error Type: Port/Network Connectivity

  • PowerShell:
    TcpTestSucceeded : False
  • ldapsearch:
    ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
  • ldp.exe:
    Error: Cannot open connection. 
Error: <0x51>: Fail to connect to ldap.example.com.
  • Root Cause: Port 636 is blocked, the LDAP server is not listening on 636, or DNS is misconfigured.
  • Next Step:
    • Verify port 636 listening on the server.
    • Confirm firewall rules allow access.
    • Double-check DNS resolution.

Error Type: Protocol Mismatch

  • ldp.exe:
    Error: The server is not operational.
  • ldapsearch (when using -ZZ with LDAPS URI):
    ldap_start_tls: Operations error (1)
additional info: TLS already started
  • Root Cause: Using StartTLS on LDAPS, or vice versa (wrong protocol for chosen port).
  • Next Step:
    • Use LDAPS (immediate TLS) on port 636.
    • Use StartTLS only on port 389.
    • Ensure client settings match server configuration.

Error Type: Bind (Authentication) Failures

  • ldp.exe:
    Error: <0x31>: Invalid credentials
  • ldapsearch:
    ldap_bind: Invalid credentials (49)
  • Root Cause: Bind DN or password incorrect, or account restrictions.
  • Next Step:
    • Recheck credentials.
    • Ensure account is not locked, expired, or restricted.

Always distinguish between handshake/certificate errors (which prevent even an attempted bind) and actual authentication errors (which occur only after a successful secure connection).

Best Practices, Standards Guidance, and Final Checks

Modern standards (RFC 4513) favor StartTLS (port 389) over legacy LDAPS (port 636) for new deployments. LDAPS remains relevant for compatibility with existing integrations and some legacy systems.

Non-interchangeability: LDAPS and StartTLS are not compatible—never attempt to use StartTLS on port 636 or expect LDAPS protocol on port 389.

Minimum certificate requirements:

  • SAN (Subject Alternative Name) must match: The server’s LDAPS certificate must have a SAN that exactly matches the FQDN presented by the client. Reliance on CN is deprecated and not sufficient for compliant clients.
  • CA trust: All clients must trust the full CA chain issuing the LDAPS certificate. Install any required intermediate or root CA certificates on the client operating system or application layer as applicable.
  • Server configuration: Server must be listening and serving the certificate on port 636.
  • Do not conflate port access with LDAPS functionality: Only a handshake, certificate validation, and successful bind verify LDAPS is fully operational.

Deployment checklist for LDAPS:

  • [ ] Server presents a valid, non-expired certificate with a SAN matching the server's FQDN.
  • [ ] Client trusts the certificate’s issuing CA (all intermediates included).
  • [ ] Port 636 is open and listening on the server; firewall rules allow access.
  • [ ] Appropriate protocol selected: LDAPS on port 636; never mix with StartTLS.
  • [ ] Handshake, encrypted communication, and an LDAP bind complete without errors.

Solid LDAPS integration means verifying each layer: connectivity, certificate trust, protocol negotiation, and authentication. Recognizing and correctly addressing errors at each stage—supported by the outputs of tools like ldp.exe, PowerShell, and ldapsearch—enables robust, secure directory deployments across any platform.

Sources

Related resources