| Port | 636 |
|---|---|
| Transport | TCP |
| Service | LDAPS — LDAP over TLS |
| Category | Authentication and directories |
| Range | well-known (0–1023, needs root to bind on Unix) |
| Encrypted | Yes, always (TLS or equivalent) |
| Exposure | Private network or VPN only |
Port 636 LDAPS · TCP
LDAPS: LDAP over implicit TLS. Required by many applications for binding with credentials, and by Windows for password changes via LDAP.
What runs on port 636
LDAPS: LDAP over implicit TLS. Required by many applications for binding with credentials, and by Windows for password changes via LDAP. Certificate validation is the usual stumbling block: the server certificate must match the hostname the client uses, and the client must trust the CA.
Software that uses it: Active Directory · OpenLDAP · FreeIPA · Samba AD
Should port 636 be open?
Private network or VPN only. Nothing good comes from this port being reachable from the internet. Keep it on an internal network, reach it over a VPN or an SSH tunnel, and firewall it from everything that does not need it.
- openssl s_client -connect dc:636 shows the certificate the clients will see.
- ldapsearch -H ldaps://dc:636 with LDAPTLS_CACERT set to the CA file is the standard test.
Check port 636
# on the host: is anything listening, and which process? ss -ltnp 'sport = :636' sudo lsof -i :636 # from another machine: is it reachable? nc -zv host 636 nmap -p 636 host curl -v telnet://host:636 # raw TCP connect test, Ctrl-C to leave
A port that answers from the internet when it should not is the finding; nmap from a machine outside your network (or a VPS) is the honest test, because scans from inside the LAN pass the firewall you are trying to verify.
Allow or block port 636
# ufw (Ubuntu/Debian) sudo ufw allow from 10.0.0.0/8 to any port 636 proto tcp sudo ufw deny 636/tcp # nftables nft add rule inet filter input ip saddr 10.0.0.0/8 tcp dport 636 accept nft add rule inet filter input tcp dport 636 drop # iptables (legacy) iptables -A INPUT -p tcp --dport 636 -s 10.0.0.0/8 -j ACCEPT iptables -A INPUT -p tcp --dport 636 -j DROP # firewalld sudo firewall-cmd --permanent --add-rich-rule='rule family=ipv4 source address=10.0.0.0/8 port port=636 protocol=tcp accept'
Replace 10.0.0.0/8 with the networks that need access. Allowing by source address is the rule that matters; "allow 636" with no source is just "open".
Related ports
Part of the port number reference. Ports are 16-bit numbers; see also the subnet calculator and the packet decoder, which shows ports inside TCP and UDP headers.
Questions
Is port 636 TCP or UDP?
TCP. LDAPS is a connection-oriented protocol; there is no UDP service on 636 by default (a scanner reporting UDP 636 open is usually seeing a filtered port).
Is port 636 encrypted?
Yes, always (TLS or equivalent). The port number does not make it safe by itself: certificate validation, authentication and patching still decide.
How do I check whether port 636 is open?
On the server, ss -ltnp (or -lunp for UDP) shows whether something listens on 636 and which process. From another machine, nc -zv host 636 or nmap -p 636 host tests reachability. "Open" in a scan means something answered; a firewall usually makes the port filtered (no answer) rather than closed (RST).
Can LDAPS run on a different port?
Yes; the number is a convention, not a requirement. Changing it reduces log noise from scanners but does not add security, and every client, firewall rule and monitoring check then needs the new number. Keep the default unless you have a concrete reason.