Port 636TCP
Le port 636/TCP est associé à LDAPS, c’est-à-dire LDAP protégé par TLS. Il permet d’interroger un annuaire via une connexion chiffrée et dépend notamment d’un certificat serveur valide, d’une résolution de nom cohérente et d’une chaîne de confiance correcte côté client.
En pratique, le port 636/TCP sert aux échanges LDAP chiffrés dès la connexion, notamment avec les contrôleurs de domaine Active Directory. Le port 389 sert à LDAP et peut négocier StartTLS ; le port 3269 correspond au catalogue global sécurisé.
À quoi sert le port 636 ?
Le port 636/TCP est utilisé pour LDAP protégé par TLS dès l’établissement de la connexion, souvent appelé LDAPS. Le serveur doit présenter un certificat que le client peut valider pour le nom utilisé. Un port 636 joignable ne garantit donc pas que la liaison LDAP aboutira : chaîne de confiance, nom du certificat et politiques TLS peuvent encore provoquer l’échec.
Protocole de transport
TCP
Précautions de sécurité
Vérifier le certificat du serveur et sa chaîne de confiance.
Faut-il ouvrir ce port dans le firewall ?
LDAPS sert justement à protéger les échanges LDAP ; évitez de contourner une erreur de certificat en désactivant la validation côté client. Limitez 636 aux applications et réseaux qui utilisent l’annuaire et maintenez le certificat du serveur à jour. Si une application exige un transport chiffré, vérifiez également qu’elle ne retombe pas silencieusement sur un flux LDAP non protégé.
Comment vérifier ce port ?
Commencez par Test-NetConnection SERVEUR -Port 636. Pour examiner TLS, openssl s_client -connect SERVEUR:636 -servername SERVEUR permet de voir le certificat et la chaîne présentés. Sous Windows, ldp.exe peut aussi tester une connexion LDAP SSL.
- Vérifier le nom DNS utilisé par le client.
- Contrôler dates, SAN/CN et chaîne du certificat serveur.
- Valider la négociation TLS avant d’analyser bind et droits LDAP.
- Examiner les journaux du client et du service d’annuaire si le bind échoue.
FAQ — port 636 / LDAPS
Pourquoi LDAPS 636 répond mais le bind échoue ?
La connexion TCP peut réussir alors que TLS, le certificat, l’authentification ou les droits LDAP échouent ensuite.
Quel certificat faut-il vérifier pour LDAPS ?
Le certificat présenté par le serveur LDAP doit être valide, de confiance et correspondre au nom utilisé par le client selon la politique de la plateforme.
LDAPS et LDAP StartTLS sont-ils la même chose ?
Ils protègent tous deux LDAP avec TLS, mais LDAPS démarre TLS dès la connexion sur 636 alors que StartTLS élève une connexion LDAP existante.
Checklist rapide : LDAPS 636 inaccessible ou erreur TLS
- Vérifiez que le FQDN du contrôleur de domaine résout vers la bonne adresse et que le flux TCP 636 est autorisé uniquement depuis les clients concernés.
- Testez le réseau avec Test-NetConnection dc01.exemple.local -Port 636, puis contrôlez la négociation TLS avec un outil compatible comme openssl s_client -connect dc01.exemple.local:636 -servername dc01.exemple.local.
- Sur Active Directory, vérifiez que le certificat possède une clé privée, l’usage Server Authentication, un nom DNS adapté et une chaîne d’autorités approuvée.
- Si TLS réussit mais que le bind échoue, vérifiez séparément l’identité, les droits LDAP et les journaux client/serveur.