我有一台装有 Fiery 8e Release 2 的打印机。我可以使用 LDAP 配置根据 AD 对用户进行身份验证，但只有在不使用 SSL/TLS 并且使用 SIMPLE 身份验证的情况下才能使其正常工作。目前，它使用影响较小的用户进行身份验证，但它也是我们网络上唯一不使用 LDAPS 的系统。
我可以使用 ldp.exe 从我的机器、防火墙、邮件过滤器、Linux 机箱等通过 LDAPS 获取 AD 信息。唯一的问题是 Fiery。
我已将 LDAP 服务器证书作为受信任的证书添加到 Fiery，但是在我选中“安全通信”复选框并将端口更改为 636 后，按“验证”会导致出现一个对话框，提示“LDAP 验证失败，服务器名称无效或服务器不可用”。
我尝试将服务器名称更改为仅使用名称、FQDN 和 IP 地址，并将其更改为另一台服务器，只是为了看看是否只有这台 AD 服务器对 Fiery 很挑剔。
编辑：删除了 LDP 输出，添加了来自 wireshark 的数据包捕获分析：在我看来，对话似乎很正常，直到 Fiery 在服务器发回握手响应后终止连接。也许他们搞砸了他们的 TLS 实现？我正在尝试支持，但到目前为止它几乎没用。该证书是 SHA-2 (sha256RSA) 2048 位证书。此外，Fiery 似乎指定了 TLS 1.0。查看http://msdn.microsoft.com/en-us/library/windows/desktop/aa374757(v=vs.85).aspx，我没有看到 SChannel 支持 SHA256 和 TLS 1.0 组合。床头柜也许这就是为什么在 DC 更改密码规范后，Fiery 会终止连接？DC 上启用了 TLS 1.1 和 1.2。
Wireshark 对话：DC：172.17.2.22，Fiery：172.17.2.42
No.Time Source Port Destination Port Protocol Length Info
1 0.000000000 172.17.2.42 48633 172.17.2.22 ldaps TCP 74 48633 > ldaps [SYN] Seq=0 Win=5840 Len=0 MSS=1460 SACK_PERM=1 TSval=3101761 TSecr=0 WS=4
2 0.000182000 Dell_5e:94:e3 Broadcast ARP 60 Who has 172.17.2.42? Tell 172.17.2.22
3 0.000369000 TyanComp_c9:0f:90 Dell_5e:94:e3 ARP 60 172.17.2.42 is at 00:e0:81:c9:0f:90
4 0.000370000 172.17.2.22 ldaps 172.17.2.42 48633 TCP 74 ldaps > 48633 [SYN, ACK] Seq=0 Ack=1 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1 TSval=67970573 TSecr=3101761
5 0.000548000 172.17.2.42 48633 172.17.2.22 ldaps TCP 66 48633 > ldaps [ACK] Seq=1 Ack=1 Win=5840 Len=0 TSval=3101761 TSecr=67970573
6 0.001000000 172.17.2.42 48633 172.17.2.22 ldaps TLSv1 147 Client Hello
7 0.001326000 172.17.2.22 ldaps 172.17.2.42 48633 TCP 1514 [TCP segment of a reassembled PDU]
8 0.001513000 172.17.2.22 ldaps 172.17.2.42 48633 TCP 1514 [TCP segment of a reassembled PDU]
9 0.001515000 172.17.2.42 48633 172.17.2.22 ldaps TCP 66 48633 > ldaps [ACK] Seq=82 Ack=1449 Win=8736 Len=0 TSval=3101761 TSecr=67970573
10 0.001516000 172.17.2.42 48633 172.17.2.22 ldaps TCP 66 48633 > ldaps [ACK] Seq=82 Ack=2897 Win=11632 Len=0 TSval=3101761 TSecr=67970573
11 0.001732000 172.17.2.22 ldaps 172.17.2.42 48633 TCP 1514 [TCP segment of a reassembled PDU]
12 0.001737000 172.17.2.22 ldaps 172.17.2.42 48633 TLSv1 1243 Server Hello, Certificate, Certificate Request, Server Hello Done
13 0.001738000 172.17.2.42 48633 172.17.2.22 ldaps TCP 66 48633 > ldaps [ACK] Seq=82 Ack=4345 Win=14528 Len=0 TSval=3101761 TSecr=67970573
14 0.001739000 172.17.2.42 48633 172.17.2.22 ldaps TCP 66 48633 > ldaps [ACK] Seq=82 Ack=5522 Win=17424 Len=0 TSval=3101761 TSecr=67970573
15 0.002906000 172.17.2.42 48633 172.17.2.22 ldaps TLSv1 78 Certificate
16 0.004155000 172.17.2.42 48633 172.17.2.22 ldaps TLSv1 333 Client Key Exchange
17 0.004338000 172.17.2.22 ldaps 172.17.2.42 48633 TCP 66 ldaps > 48633 [ACK] Seq=5522 Ack=361 Win=66304 Len=0 TSval=67970573 TSecr=3101762
18 0.004338000 172.17.2.42 48633 172.17.2.22 ldaps TLSv1 72 Change Cipher Spec
19 0.005481000 172.17.2.42 48633 172.17.2.22 ldaps TLSv1 327 Encrypted Handshake Message
20 0.005645000 172.17.2.22 ldaps 172.17.2.42 48633 TCP 66 ldaps > 48633 [ACK] Seq=5522 Ack=628 Win=66048 Len=0 TSval=67970574 TSecr=3101762
21 0.010247000 172.17.2.22 ldaps 172.17.2.42 48633 TLSv1 125 Change Cipher Spec, Encrypted Handshake Message
22 0.016451000 172.17.2.42 48633 172.17.2.22 ldaps TCP 66 48633 > ldaps [FIN, ACK] Seq=628 Ack=5581 Win=17424 Len=0 TSval=3101765 TSecr=67970574
23 0.016630000 172.17.2.22 ldaps 172.17.2.42 48633 TCP 66 ldaps > 48633 [ACK] Seq=5581 Ack=629 Win=66048 Len=0 TSval=67970575 TSecr=3101765
24 0.016811000 172.17.2.22 ldaps 172.17.2.42 48633 TCP 60 ldaps > 48633 [RST, ACK] Seq=5581 Ack=629 Win=0 Len=0
编辑：在最近的 SCHANNEL 修补和 POODLE 提示更改我们的密码管理后重新审视了这个问题，但我仍然遇到这个问题。
编辑：解决@DTK 的答案：已添加根 CA。重新添加到测试。正在使用 DC FQDN，证书与 FQDN 匹配，在 DNS 中正确解析。客户端可以使用 LDAP 顺利访问 DC。其他客户端可以顺利访问同一 DC 上的 LDAPS。DC 支持 TLS 1.0、1.1 和 1.2。使用简单身份验证。公钥是使用 SHA256 签名的 RSA 2048 位。
以下是 HKLM\SOFTWARE\Policies\Microsoft\Cryptography\Configuration\SSL\00010002 中 SCHANNEL 支持的密码（按密码顺序）：
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P521 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P521 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P521 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P384 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P521 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256 TLS_RSA_WITH_AES_256_GCM_SHA384 TLS_RSA_WITH_AES_128_GCM_SHA256 TLS_RSA_WITH_AES_256_CBC_SHA256 TLS_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA256 TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA
答案1
要使 LDAPS 正常工作，您需要具备以下所有条件：
- 配置客户端以信任颁发证书的 CA（或者如果使用分层 PKI，则信任根 CA）
- 配置客户端通过 FQDN 访问域控制器服务器
- 域控制器服务器的 FQDN 必须在 DNS 中正确解析
- 客户端中配置的域控制器服务器的 FQDN 必须与用于 TLS 的证书中的 SubjectCN 匹配或者必须与用于 TLS 的证书中的 SubjectAlternativeName 中的一个条目匹配
- 如果客户端设备不使用 Kerberos（特别是与 AD 兼容的 Kerberos），则必须使用简单身份验证
- SASL 不起作用，尝试使用它将异常结束并显示无用的错误消息
- 客户端和服务器必须支持一组通用的 TLS 协议版本（最好是 TLS 1.1 或更高版本）和一组通用的算法（密钥交换、身份验证、对称密钥密码和哈希/MAC）
- KEX : RSA, DHE, ECDHE
- AuthN：RSA、DSA、ECDSA
- 密码：AES-CBC、AES-GCM（天哪，不是 RC4、DES 或 3DES）
- 哈希：SHA、SHA256/384/512（请不要使用 MD2 或 MD5）
- 客户端和服务器必须支持通用密钥长度
- RSA：2048 位或 4096 位公钥长度
- DSA：2048 位公钥长度（如果支持；许多仅支持 1024 位密钥）
- ECDSA/ECDHE ：283 位或更长，基于https://www.rfc-editor.org/rfc/rfc4492
- AES：128 位或更长
- SHA* ：256 位或更大存储桶大小/摘要长度
答案2
Fiery 不需要直接信任 LDAP 服务器证书。它应该信任签署 LDAP 服务器证书的 CA 或 CA 链。
此外，LDAP 服务器证书是否包含对 CRL 检查位置或 OSCP 服务器的引用？如果是，Fiery 的网络连接是否可以访问该位置？证书可能有效，但 Fiery 可能无法正确检查它是否已被撤销。
可能发生的另一种（不常见的）事情是，Fiery 是否因证书密钥长度等问题而受阻。