636

Port 636/tcp is LDAPS — LDAP over implicit TLS, where the TLS handshake completes on connect and the directory session runs encrypted from the first byte. It is the implicit-TLS counterpart to plaintext LDAP-plus-StartTLS on port 389, and it is heavily used in Microsoft Active Directory and any environment that requires encrypted directory traffic. The directory semantics are identical to 389 (bind, search, compare, modify over a Directory Information Tree of DN-addressed entries); the difference is purely the transport security. Historically the ldaps:// scheme predates StartTLS and was never standardized to the same degree, but it is universally deployed and IANA-registered — the registry description reads literally "ldap protocol over TLS/SSL (was sldap)", with assignee Pat Richard and a blank reference field, so the LDAP RFCs are the governing specifications but not the IANA-cited reference. Encryption defeats the cleartext-credential capture and sniffing that plague plaintext 389, but 636 is still subject to credential brute-force (tools like hydra's ldap modules and Metasploit's ldap_login), to certificate-validation weaknesses where clients ignore certificate errors, and to full post-authentication directory reconnaissance — once a client is bound, the directory data is just as enumerable as over 389. When Active Directory is hardened to require LDAP signing/channel binding, clients attempting plaintext binds on 389 receive "the server requires binds to turn on integrity checking" errors and are pushed toward 636 or StartTLS. For an analyst, an open 636 (typically alongside 389 and 88) is a strong Active Directory Domain Controller signal; validate the certificate and TLS version and confirm whether legacy/anonymous access is disabled.

IANA assignment

ldaps — "ldap protocol over TLS/SSL (was sldap)"; reference (blank — no RFC cited in IANA registry); assignee/contact Pat Richard; governing protocol the LDAPv3 RFCs (RFC 4511/4513, not the IANA-cited reference) [IANA-assigned] — IANA Service Name and Transport Protocol Port Number Registry

Range class

well-known (0–1023)

Prevalence

common on AD/enterprise networks (de-facto, nmap-services; nmap labels it ldapssl) [Well-established] — nmap-services file

Related ports

389 (LDAP cleartext/StartTLS); 3268/3269 (AD Global Catalog LDAP/LDAPS); 88 (Kerberos) and 445 (SMB) in the AD cluster

Primary use

LDAP directory access over implicit TLS; widely used in Active Directory

Other/unofficial uses

encrypted directory-backed authentication for identity appliances [Well-established]

Security implications

implicit TLS protects credentials and defeats sniffing/MITM; still subject to credential brute-force; certificate-validation weaknesses; post-authentication AD reconnaissance remains possible

Typically seen on

Active Directory Domain Controllers, hardened OpenLDAP, identity appliances

Analyst note

Open 636 (especially with 389 and 88) strongly suggests an Active Directory Domain Controller. Validate the certificate and TLS version and confirm whether legacy/anonymous access is disabled.

Port 636/udp is registered with IANA as ldaps — "ldap protocol over TLS/SSL (was sldap)" — with assignee/contact Pat Richard and a blank reference field, dual-registered alongside 636/tcp which carries the same service name, description, and contact. The UDP registration, however, is effectively a non-functional placeholder. LDAPS is the secure variant of the Lightweight Directory Access Protocol that wraps LDAP in a TLS/SSL session, and a TLS handshake requires the reliable, ordered, stateful delivery that only TCP provides; UDP's connectionless datagram model cannot carry the handshake, so no production software implements LDAPS over UDP. The UDP row exists because IANA commonly mirrors a TCP assignment onto UDP for dual-stack tidiness even when one transport is inapplicable — the same legacy pattern seen across many well-known ports. For an analyst this matters because all real-world deployment, exposure, and risk for port 636 lives on the TCP side: Microsoft Active Directory, OpenLDAP, 389 Directory Server, FreeIPA, and similar directory servers listen for LDAPS on 636/tcp, and internet scanners such as Shodan banner-grab the TCP port for certificate and TLS-configuration assessment. 636/udp returns no banners, appears in no scanner active-surface datasets, and has no UDP-specific CVEs. A responsive or "open|filtered" 636/udp in a scan is far more likely to be a scanner artifact than a real LDAPS endpoint, and the secure-directory exposure questions an analyst cares about (self-signed or expired certificates, weak ciphers, MitM risk) all belong to 636/tcp.

IANA assignment

ldaps — "ldap protocol over TLS/SSL (was sldap)"; reference (blank — no RFC cited in IANA registry); assignee/contact Pat Richard; dual-registered 636/tcp + 636/udp [Confirmed] — the IANA Service Name and Transport Protocol Port Number Registry line 1301; https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=636

Range class

well-known (0–1023) [Confirmed]

Related ports

389/tcp (LDAP, StartTLS); 636/tcp (LDAPS, the functional variant); 3268–3269/tcp (AD Global Catalog / GC over SSL)

Primary use

registered name for LDAP over TLS/SSL; on UDP this is a mirror of the TCP assignment with no functional protocol — LDAPS requires TCP for its TLS handshake

Other/unofficial uses

none documented for the UDP variant; all LDAPS implementations bind 636/tcp

Common software (TCP side only)

Microsoft Active Directory, OpenLDAP, 389 Directory Server, Apache Directory Server, FreeIPA, Oracle Directory Server, IBM Security Directory Server [Likely] — https://scanitex.com/en/resources/ports/tcp/636 ; https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/enable-ldap-over-ssl-3rd-certification-authority

Exposure / scanning

636/udp returns no banners and does not appear as an active surface in scanner datasets (e.g., Shodan); all banner-grabbing and exposure assessment for port 636 targets the TCP side

Security implications

no UDP-specific CVEs or malware. TCP-side LDAPS exposure risks (self-signed/expired certs, weak TLS ciphers, MitM) and ecosystem CVEs (e.g., POODLE CVE-2014-3566, BEAST CVE-2011-3389) apply to 636/tcp, NOT to 636/udp

Typically seen on

nothing legitimately; an open|filtered 636/udp is most likely a scan artifact rather than a real service

Analyst note

Treat 636/udp as a registered-but-unused placeholder. Pivot any LDAPS investigation to 636/tcp, where the certificates, banners, and real risk live.