Ports

Port 636: LDAPS

LDAP over implicit TLS. Common for secure directory binds and searches.

Where you will see it: You will see this in scans, firewall rules, vulnerability reports, and service configs. Treat open ports as exposure points and verify the service is expected, hardened, and restricted.

What it is

TCP port 636 is used for LDAPS, which is LDAP with TLS from the first byte. A port is a transport layer number used together with an IP address and a protocol such as TCP or UDP to direct traffic to the correct service on a host. A server process binds a socket to a port and listens, while a client typically chooses an ephemeral source port for outbound connections.

The combination of source and destination IP addresses, source and destination ports, and the transport protocol uniquely identifies a flow so the operating system can keep many conversations separate. Firewalls, NAT, and scanners talk about ports because the destination port is the stable rendezvous point that exposes a service to the network.

A directory server listens on 636 for clients that require encryption immediately, rather than connecting on 389 and negotiating StartTLS. The real flow is: TCP handshake, then TLS handshake with certificate validation, then LDAP bind and directory operations inside the encrypted session.

This protects credentials and directory attributes in transit, but it does not automatically make directory access safe. Permissions, service account scope, and monitoring still determine how much data is exposed if an account is compromised.

Operationally, certificate trust matters a lot here. If clients cannot validate the LDAPS certificate, authentication can fail at scale or users may learn to ignore warnings.

How it works in broad strokes

Client connects and starts a TLS handshake immediately, validating the server certificate.
Client performs an LDAP bind inside the encrypted channel.
Client runs searches and reads attributes, then closes the connection or reuses it for multiple operations.

Concrete example

An internal service verifies user group membership. It connects to 636, validates the directory certificate, then performs an LDAP search over the encrypted channel.

Why it matters

Secure directory traffic prevents credential theft and attribute leakage. LDAPS is common in enterprise apps that integrate with directories. Misconfigured LDAPS certificates can break authentication at scale, so understanding it matters operationally too.

Security angle

Use certificates issued by a trusted internal PKI and automate renewal.
Restrict access to known application subnets and monitor bind patterns.
Harden directory permissions so services only read what they need.

Common pitfalls

Using self signed certificates without proper trust distribution, causing client failures.
Treating LDAPS as automatically safe while still allowing weak binds or broad reads.
Opening 636 to networks that should never query the directory.