Windows AD 默认不监听 LDAPS 636 端口，需手动启用服务并绑定满足密钥可导出、EKU含Server Authentication、SAN匹配访问域名等条件的证书，且须为NETWORK SERVICE授权私钥读取权限、重启AD服务，并在客户端信任证书链，最后用openssl验证TLS握手成功。
ldaps 不是简单配个证书就能通的，windows ad 默认不监听 ldaps 636 端口，必须手动启用并绑定有效证书——否则客户端连 ldap:// 都能通，ldaps:// 一定超时或报错 can't contact ldap server。
AD 域控制器上必须启用 LDAPS 服务（不是装完证书就自动开）
AD 不像 OpenLDAP，默认不监听 636 端口。即使你已导入证书到本地计算机「个人」存储，服务仍处于关闭状态。
- 证书必须满足：密钥可导出、增强型密钥用法（EKU）包含
Server Authentication（OID1.3.6.1.5.5.7.3.1）、主题名称或 SAN 必须匹配客户端连接时使用的域名（如dc.example.com，不能只写 IP） - 运行
certlm.msc→ 导入证书到「个人」→「证书」节点 → 右键证书 →所有任务 → 管理私钥→ 添加NETWORK SERVICE读取权限（否则NTDS服务无法加载） - 重启
Active Directory Domain Services服务（或直接重启服务器），系统会自动检测并绑定证书到 636 端口 —— 可用netstat -ano | findstr :636验证是否监听
客户端连接 LDAPS 前必须信任 AD 证书链（尤其自签名或内网 CA）
Linux/macOS 客户端默认不信任 Windows 内网 CA 根证书，ldapsearch -H ldaps://dc.example.com -x -D "user@EXAMPLE.COM" -W 会直接失败，报错类似 TLS: can't connect: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed。
- 若证书由企业内网 CA 签发：把根 CA 证书（.crt 或 .pem）拷贝到客户端，执行
sudo cp ca-root.crt /etc/ssl/certs/→sudo update-ca-certificates（Ubuntu/Debian）或sudo trust anchor --store ca-root.crt（RHEL/Fedora） - 若用自签名证书：不能只加
LDAPTLS_REQCERT never（不安全且部分工具如sssd会忽略），必须把该证书显式加入信任库；OpenLDAP 客户端可通过LDAPTLS_CACERT=/path/to/dc.crt环境变量指定 - Windows 客户端（如 PowerShell
Get-ADUser）依赖系统证书存储，需将根 CA 导入「受信任的根证书颁发机构」
验证 LDAPS 是否真正生效（别只信端口通）
仅 telnet dc.example.com 636 成功 ≠ LDAPS 可用。它只说明 TCP 层通，没验证 TLS 握手和证书链有效性。
- 用 OpenSSL 手动测试完整 TLS 握手：
openssl s_client -connect dc.example.com:636 -showcerts -servername dc.example.com—— 关键看输出末尾是否含Verify return code: 0 (ok) - 若返回
Verify return code: 21 (unable to verify the first certificate)，说明客户端找不到根证书或中间证书缺失 - PowerShell 中禁用证书验证（仅调试）：
$env:LDAPTLS_REQCERT="never"，但生产环境严禁此配置；Java 应用需额外配置javax.net.ssl.trustStore
最容易被跳过的一步：证书的 Subject Alternative Name (SAN) 必须包含客户端实际访问的 FQDN。用 IP 地址连 ldaps://192.168.1.10 却只在证书里写了 dc.example.com？TLS 握手会因主机名不匹配直接中断——这个错误不会报“证书过期”，而是静默失败或显示模糊的连接重置。
