I've got a printer with a Fiery running 8e Release 2. I can authenticate users against AD using the LDAP configuration, but I can only get it to work if I don't use SSL/TLS, and only if I use SIMPLE authentication. Right now, it's authenticating using a fairly low-impact user, but it's also the only system on our network that's not using LDAPS.

I can get AD info fine over LDAPS using ldp.exe from my machine, our firewall, our mail filter, our linux boxes, etc. The only problem child is the Fiery.

I've added the LDAP server certificate as a trusted cert to the Fiery, but after I check the box for Secure Communication and change the port to 636, pressing Validate results in a dialog box coming up saying: LDAP Validation Failed Server Name invalid or server is unavailable.

I've tried changing the server name to use just the name, the FQDN, and the IP address, and changed it to another server, just to see if it was just this AD server that was fussy with the Fiery.

EDIT: removed LDP output, added packet capture analysis from wireshark: The conversation seems pretty normal to me, up to the point where the Fiery terminates the connection after the server sends back a handshake response. Maybe they messed up their TLS implementation? I'm trying support, but it's been fairly useless so far. The cert is a SHA-2 (sha256RSA) 2048-bit certificate. Also, it looks like the Fiery is specifying TLS 1.0. Looking at http://msdn.microsoft.com/en-us/library/windows/desktop/aa374757(v=vs.85).aspx, I'm not seeing SHA256 and TLS 1.0 combination being supported by SChannel. headdesk perhaps that's why, after the DC changes the cipher spec, the connection is terminated by the Fiery? TLS 1.1 and 1.2 are enabled on the DC.

Wireshark conversation: DC:, Fiery:

No.Time        Source            Port Destination  Port  Protocol Length Info
1  0.000000000      48633  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  Tell
3  0.000369000 TyanComp_c9:0f:90      Dell_5e:94:e3      ARP      60 is at 00:e0:81:c9:0f:90
4  0.000370000      ldaps  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      48633  ldaps TCP      66     48633 > ldaps [ACK] Seq=1 Ack=1 Win=5840 Len=0 TSval=3101761 TSecr=67970573
6  0.001000000      48633  ldaps TLSv1    147    Client Hello
7  0.001326000      ldaps  48633 TCP      1514   [TCP segment of a reassembled PDU]
8  0.001513000      ldaps  48633 TCP      1514   [TCP segment of a reassembled PDU]
9  0.001515000      48633  ldaps TCP      66     48633 > ldaps [ACK] Seq=82 Ack=1449 Win=8736 Len=0 TSval=3101761 TSecr=67970573
10 0.001516000      48633  ldaps TCP      66     48633 > ldaps [ACK] Seq=82 Ack=2897 Win=11632 Len=0 TSval=3101761 TSecr=67970573
11 0.001732000      ldaps  48633 TCP      1514   [TCP segment of a reassembled PDU]
12 0.001737000      ldaps  48633 TLSv1    1243   Server Hello, Certificate, Certificate Request, Server Hello Done
13 0.001738000      48633  ldaps TCP      66     48633 > ldaps [ACK] Seq=82 Ack=4345 Win=14528 Len=0 TSval=3101761 TSecr=67970573
14 0.001739000      48633  ldaps TCP      66     48633 > ldaps [ACK] Seq=82 Ack=5522 Win=17424 Len=0 TSval=3101761 TSecr=67970573
15 0.002906000      48633  ldaps TLSv1    78     Certificate
16 0.004155000      48633  ldaps TLSv1    333    Client Key Exchange
17 0.004338000      ldaps  48633 TCP      66     ldaps > 48633 [ACK] Seq=5522 Ack=361 Win=66304 Len=0 TSval=67970573 TSecr=3101762
18 0.004338000      48633  ldaps TLSv1    72     Change Cipher Spec
19 0.005481000      48633  ldaps TLSv1    327    Encrypted Handshake Message
20 0.005645000      ldaps  48633 TCP      66     ldaps > 48633 [ACK] Seq=5522 Ack=628 Win=66048 Len=0 TSval=67970574 TSecr=3101762
21 0.010247000      ldaps  48633 TLSv1    125    Change Cipher Spec, Encrypted Handshake Message
22 0.016451000      48633  ldaps TCP      66     48633 > ldaps [FIN, ACK] Seq=628 Ack=5581 Win=17424 Len=0 TSval=3101765 TSecr=67970574
23 0.016630000      ldaps  48633 TCP      66     ldaps > 48633 [ACK] Seq=5581 Ack=629 Win=66048 Len=0 TSval=67970575 TSecr=3101765
24 0.016811000      ldaps  48633 TCP      60     ldaps > 48633 [RST, ACK] Seq=5581 Ack=629 Win=0 Len=0

EDIT: revisited this issue after the recent SCHANNEL patching and POODLE prompted changing our cipher management, and I'm still having this issue.

EDIT: addressing @DTK's answer: Root CA added already. Readded to test. DC FQDN being used, cert matches FQDN, resolves correctly in DNS. Client can access DC using LDAP just fine. Other clients reach LDAPS on same DC just fine. DC supports TLS 1.0, 1.1, and 1.2. Using Simple Auth. Public key is RSA 2048 bit signed with SHA256.

Here's the supported ciphers in cipher order for SCHANNEL from HKLM\SOFTWARE\Policies\Microsoft\Cryptography\Configuration\SSL\00010002:


  • Have you tried to do a wireshark capture between the printer and LDAPS server? Do you see the printer trying to connect to port 636 like you expect? Do you see the LDAPS system responding?
    – Zoredache
    Jun 3, 2014 at 22:33
  • facepalm Good idea! Will do as soon as I can. (Haven't had to wireshark in a while which is why I forgot.)
    – austinian
    Jun 5, 2014 at 12:33
  • Alright, I just enabled TLS 1.1 and 1.2 support on the DC, still no change in handshake behavior.
    – austinian
    Jun 5, 2014 at 18:28

2 Answers 2


You need to have all of the following for LDAPS to work:

  • Configure the client to trust the CA that issued the certificate (or if using a hierarchical PKI, the root CA)
  • Configure the client to access the Domain Controller server via FQDN
  • The FQDN of the Domain Controller server must resolve correctly in DNS
  • The FQDN of the Domain Controller server configured in the client must match the SubjectCN in the certificate used for TLS OR must match one of the entries in the SubjectAlternativeName in the certificate used for TLS
  • If the client device does not use Kerberos (and specifically an AD-compatible Kerberos), you must use Simple Auth
    • SASL will not work, and attempting to use it will ABEND with an unhelpful error message
  • The client and server must support a common set of TLS Protocol Versions (Preferably TLS 1.1 or later) and a common set of algorithms (Key Exchange, Authentication, Symmetric-key Cipher and Hash/MAC)
    • AuthN : RSA, DSA, ECDSA
    • Cipher : AES-CBC, AES-GCM (oh dear gods, not RC4, DES or 3DES)
    • Hash : SHA, SHA256/384/512 (please, please, not MD2 or MD5)
  • The client and server must support common key-lengths
    • RSA : 2048 bit or 4096 bit public-key-length
    • DSA : 2048 bit public-key-length (if supported ; many only support 1024 bit keys)
    • ECDSA/ECDHE : 283 bit or longer, based on https://www.rfc-editor.org/rfc/rfc4492
    • AES : 128 bit or longer
    • SHA* : 256 bit or larger bucket-size / digest-length
  • Too long for a comment, I'm going to address these points in an edit to my question.
    – austinian
    Nov 29, 2014 at 3:17
  • Thank you. Great additional information. Out of curiosity, do we know for sure that the client (Fiery) supports AES ? And do we know whether it is attempting a secure renegotiation? It looks like the AD DC is closing the connection after the Fiery client asks "Change Cipher Spec".
    – DTK
    Nov 29, 2014 at 6:34
  • @austinian just for testing purposes, can you try adding <code>TLS_RSA_WITH_RC4_SHA</code> to see if it magically starts working?
    – DTK
    Nov 29, 2014 at 11:13
  • @austinian just for testing purposes, can you try adding TLS_RSA_WITH_RC4_SHA to see if it magically starts working? It may not support AES and that is the only symmetric-key cipher I saw in your list.
    – DTK
    Nov 29, 2014 at 11:20
  • @austinian Also if your Windows AD DC is enforcing clients to handle renegotiation correctly or GTFO, that may be what is causing the connection closures. It looks like the EFI Fiery firmware is based (in small part) on an old version of OpenSSL (0.98.o) that may not do renegotiation correctly.
    – DTK
    Nov 29, 2014 at 11:22

The Fiery shouldn't need to trust the LDAP server certificate directly. It should be trusting the CA or chain of CAs that signed the LDAP server certificate.

Additionally, does the LDAP server certificate contain references to a CRL checking location or OSCP server? And if so, does the Fiery's network connectivity have access to that location(s)? The cert may be valid, but the Fiery might not be able to properly check that it hasn't been revoked.

Another (uncommon) thing that might be going on is if the Fiery is choking on something like the key length of the certificate.

  • I added the root CA, then the intermediate CAs, then the cert itself without it working. The Cert does reference a CRL, which I can reach from other machines on my network, and I'm not blocking traffic specifically from the printer to the internet (it gets regular updates from internet sources). The key is a 2048 bit RSA key, or are you referring to the key and its properties as a total data length issue?
    – austinian
    Jun 5, 2014 at 12:30
  • From the wiresharking done earlier, it doesn't appear that the CRL is checked before the connection is terminated.
    – austinian
    Jun 5, 2014 at 18:39

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .