Jenkins对接LDAPS协议AD时使用JDK TrustStore绑定失败排查

核心认知前提：AD插件选择「JDK Trustore」选项发起LDAPS连接时，使用的是Jenkins进程所属JVM的客户端出站连接信任库，和你当前配置的JENKINS_HTTPS_KEYSTORE完全无关——后者是Jenkins自身对外提供HTTPS服务时用的服务端密钥库，不会被用于出站SSL连接的证书校验，这是90%同类故障的根因。

可按以下优先级逐一排查：

• 确认证书导入的目标路径正确
  你当前往/etc/ssl/certs/example.ca.jks导入证书的操作完全不生效。先通过ps aux | grep jenkins拿到Jenkins进程调用的java可执行文件路径，定位对应JDK的默认信任库位置，通常路径为$JAVA_HOME/jre/lib/security/cacerts，该文件默认密码为changeit。你需要将AD域控的完整证书链导入到这个cacerts文件中，而非自定义的HTTPS服务密钥库。
• 确认证书链导入完整
  仅导入636端口返回的域控叶子证书会导致证书路径校验失败，需通过openssl s_client -connect example.com.tw:636 -showcerts拉取从根CA到域控叶子节点的完整证书链，将所有层级证书按顺序导入信任库，不要遗漏中间CA证书。
• 若需使用自定义信任库，检查JVM参数配置是否正确且生效
  如果不想修改JDK默认cacerts文件，需要在/etc/systemd/system/jenkins.service中配置的是JVM全局信任库参数，而非HTTPS服务密钥库参数，正确配置示例：

  Environment="JAVA_OPTS=-Djavax.net.ssl.trustStore=/etc/ssl/certs/example.ca.jks -Djavax.net.ssl.trustStorePassword=XXX"
  

  修改配置后必须依次执行systemctl daemon-reload、systemctl restart jenkins，重启后再次通过ps aux | grep java检查Jenkins进程启动参数，确认上述两个javax.net.ssl.trustStore参数已正确加载，未加载则说明配置未被systemd识别。
• 检查信任库文件权限
  Jenkins默认以jenkins系统用户运行，需确认信任库文件对该用户可读，可执行chmod 644 /path/to/truststore配置全局读权限，避免因权限不足导致JVM无法读取信任库内容。
• 校验证书本身有效性
  确认导入的证书在有效期内，且证书的CN/SAN扩展字段包含你连接使用的域名example.com.tw；如果域控侧近期更新过SSL证书（比如旧证书到期轮换），本地信任库存的旧证书会直接导致校验失败，需重新导入新的证书链。
• 检查是否存在配置覆盖
  进入Jenkins全局安全配置、插件管理页面，确认是否安装了自定义SSL证书管理类插件，这类插件可能覆写JVM默认的信任库加载逻辑，导致AD插件没有读取你导入证书的目标文件。

注：「(unsecure)Trust all Certificates」模式仅能证明LDAP服务网络连通性正常、绑定账号密码正确，该模式会跳过所有SSL证书校验逻辑，无法用于验证证书配置正确性。

内容的提问来源于stack exchange，提问作者Daniel YC Lin