使用EFI Fiery打印机的LDAP over SSL

我有一台运行8e Release 2的Fiery打印机。我可以使用LDAPconfiguration对AD进行身份validation，但是如果我不使用SSL / TLS，只有在使用SIMPLE身份validation时才能使用它。目前，它使用的是影响相对较小的用户进行身份validation，但是它也是我们networking中不使用LDAPS的唯一系统。

我可以使用从我的机器，我们的防火墙，我们的邮件filter，我们的Linux盒等ldp.exe的LDAPS AD信息很好。唯一的问题是Fiery。

我已经将LDAP服务器证书添加为Fiery的可信证书，但是在选中安全通信checkbox并将端口更改为636后，按“validation”结果将出现一个对话框，提示：LDAPvalidation失败的服务器名称无效或服务器不可用。

我已经尝试改变服务器名称，只使用名称，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组合。 headdesk也许这就是为什么在DC改变密码规范后，连接被Fiery终止的原因？ TLS 1.1和1.2在DC上启用。

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提示改变我们的密码pipe理后，重新讨论这个问题，我仍然有这个问题。

编辑：寻址@ DTK的答案：根CA已经添加。 Readdedtesting。使用DC FQDN，证书与FQDN匹配，在DNS中正确parsing。客户端可以使用LDAP访问DC。其他客户也可以在同一个DC上达到LDAPS。 DC支持TLS 1.0,1.1和1.2。使用简单的身份validation 公钥是用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

您需要具备以下所有的LDAPS才能工作：

将客户端configuration为信任颁发证书的CA（或者使用分层PKI，即根CA）
configuration客户端通过FQDN访问域控制器服务器
域控制器服务器的FQDN必须在DNS中正确parsing
客户端中configuration的域控制器服务器的FQDN必须与用于TLS的证书中的SubjectCN匹配，或者必须与用于TLS的证书中的SubjectAlternativeName中的一个条目匹配
如果客户端设备不使用Kerberos（特别是与AD兼容的Kerberos），则必须使用简单身份validation
- SASL将无法正常工作，试图使用它将带来无益的错误信息
客户端和服务器必须支持一套通用的TLS协议版本（最好是TLS 1.1或更高版本）和一套通用的algorithm（密钥交换，authentication，对称密钥密码和哈希/ 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位或更长，基于http://tools.ietf.org/html/rfc4492
- AES：128位或更长
- SHA *：256位或更大的桶大小/摘要长度

Fiery不需要直接信任LDAP服务器证书。它应该信任签署LDAP服务器证书的CA或CA连锁。

另外，LDAP服务器证书是否包含对CRL检查位置或OSCP服务器的引用？如果是这样，Fiery的networking连接是否可以访问该位置？证书可能是有效的，但Fiery可能无法正确检查它是否被撤销。

另一个（不常见）的事情是，如果Fiery在证书的密钥长度等问题上感到窒息。