Port 636 LDAPS – Free, Online, Private

What listens on 636

Port 636 is LDAPS. The IANA name is ldaps, ldap protocol over TLS/SSL. The client sends a TLS ClientHello first. There is no cleartext LDAP banner. STARTTLS on port 389 is the other way to encrypt LDAP, and clients that mix the two settings fail in a way that looks like a bad certificate or a hung connect. The registry lists UDP. Directory clients use TCP. A certificate on 636 has to name the host the client dialed, which is often a load-balancer name and not the host name of one replica.

The IANA service name is ldaps: ldap protocol over TLS/SSL. The practical transport is TCP. The checks below use TCP. IANA may also have a UDP row for 636. The service described here is the TCP one. A process can bind this port without being the service in the registry. The commands show who bound it. They do not prove the protocol on the wire is the one IANA named.

Service notes for port 636

Service notes for port 636: the IANA name is ldaps (ldap protocol over TLS/SSL), and the program people mean is LDAPS. TCP 636 is the IANA ldaps port, LDAP over TLS from the first byte. Cleartext LDAP with STARTTLS is 389. TLS on 636 encrypts the bind. It does not decide who may bind. Anonymous access and weak passwords survive the move from 389. Verify certificates in the client. A client that skips verification will hand the password to any listener on 636. Keep the port on the directory network. If you only enabled 636 and left 389 open with simple binds, you did not finish the job. Nothing in that paragraph applies to a different number just because the software family is similar. If your listener is not on 636, you are on the wrong page.

The common client bug is 'use SSL' checked and the port left at 389, or unchecked and the port set to 636. Match them. A second bug is a certificate for ldap.internal presented to a client that connected to the public name. TCP succeeds, TLS fails. A third is a firewall rule copied from 389 that never got a twin for 636. A fourth is testing with nc and not seeing a banner. You will not. The first bytes are TLS.

How to check whether it is open

On the machine itself, ask the kernel which socket is bound. ss and lsof do that. A firewall, a security group, and a Docker publish rule sit in front of that socket, so a listener is not the same thing as a port the internet can use. From somewhere else, nc -vz host 636 tries a TCP handshake when the command is the TCP form. A refusal means something answered with a reset. A timeout means a filter dropped the packet or the host is unreachable. Those are different faults. Confirm TCP 636 on the directory, then run a TLS client and read the certificate name. An LDAP search over that TLS session is the full test. A cleartext banner means the daemon is not speaking LDAPS on this port.

grep and findstr match text. A pattern of :80 also matches :8080 and :8000. The lsof and Get-NetTCPConnection forms take a numeric port and do not have that substring bug. Use them when the number is ambiguous. ss filters in the kernel with sport = :N, which is also exact. On macOS, netstat -p selects a protocol. It does not print the process the way Linux netstat -p does. lsof prints the process.

• 636 is implicit TLS. 389 is cleartext plus optional STARTTLS. They are not interchangeable settings.
• No cleartext banner is normal. Do not treat that as a dead service.
• UDP 636 is not the client transport.
• A certificate mismatch fails after the TCP port looks healthy.

Linuxsudo ss -lptn 'sport = :636'
sudo lsof -nP -iTCP:636 -sTCP:LISTEN

macOSsudo lsof -nP -iTCP:636 -sTCP:LISTEN
netstat -anv -p tcp | grep '\.636[^0-9]'

Windowsnetstat -ano | findstr :636
Get-NetTCPConnection -LocalPort 636

Remotenc -vz host 636