针对你遇到的这个问题——OpenSSL 3默认拒绝SHA1签名证书，导致WordPress的Next Active Directory Integration插件没法通过StartTLS连接AD DC，我整理了一套可行的配置方案，核心是给AD添加新的强哈希证书并保留原SHA1证书作为 fallback，不用改客户端配置就能解决：

1. 为AD DC生成/申请新的强哈希算法证书（SHA256及以上） #

首先得给DC准备一个符合OpenSSL 3要求的证书，推荐用SHA256：

• 企业CA环境：如果你们有内部PKI，直接在CA控制台给DC申请「计算机」类型证书，注意要勾选「服务器身份验证（1.3.6.1.5.5.7.3.1）」作为增强型密钥用法，哈希算法选SHA256。
• 测试/无内部CA环境：用PowerShell生成自签名证书，执行以下命令（替换成你的DC域名）：

  New-SelfSignedCertificate -DnsName "dc.yourdomain.com" -CertStoreLocation "Cert:\LocalMachine\My" -KeySpec KeyExchange -KeyLength 2048 -HashAlgorithm SHA256 -Subject "CN=dc.yourdomain.com" -KeyUsage DigitalSignature,KeyEncipherment
  

• 生成/导入证书后，一定要给「NETWORK SERVICE」账户赋予该证书的读取权限：右键证书→所有任务→管理私钥→添加NETWORK SERVICE并勾选读取权限。

2. 配置AD LDAP服务启用新证书 #

AD的LDAP服务会自动识别本地计算机存储里符合要求的服务器证书，不需要额外绑定操作，但可以用工具验证：

• 打开ldp.exe（Windows自带工具），连接到DC的389端口，然后点击「连接」→「StartTLS」，在弹出的证书窗口里查看是否显示新的SHA256证书。

3. 保留原有SHA1证书作为Fallback #

完全不需要删除原有的SHA1证书，AD的LDAP服务在TLS握手时会向客户端提供所有可用的合法服务器证书，客户端会自动根据自身的算法支持和信任列表选择合适的证书：

• 对于OpenSSL 3客户端（比如你的WordPress服务器），会优先选择SHA256证书；
• 对于仍依赖SHA1的旧客户端，依然可以正常使用原证书连接。

4. 验证配置效果 #

• WordPress服务器端测试：用ldapsearch命令测试StartTLS连接（替换成你的域名）：

  ldapsearch -H ldap://dc.yourdomain.com -x -ZZ -b "dc=yourdomain,dc=com" "(objectClass=user)" sAMAccountName
  

  如果能正常返回用户列表，说明OpenSSL 3已经接受了新证书。
• 旧客户端测试：用装有OpenSSL 1.1.x或更低版本的机器测试LDAP StartTLS连接，确认依然可以正常访问。

额外注意事项 #

• 确保AD DC和WordPress服务器的系统时间同步，否则证书验证会失败；
• 如果用的是自签名证书，需要把该证书导入到WordPress服务器的OpenSSL信任存储（比如Linux下的/etc/ssl/certs/目录，或者PHP配置里的curl.cainfo指定路径）；
• 尽量不要修改OpenSSL 3的配置来启用SHA1，这会降低系统安全性，优先采用添加新证书的方案。

备注：内容来源于stack exchange，提问作者Lyndon McLaren