LDAP sobre SSL com uma impressora EFI Fiery

Question

Tenho uma impressora com um Fiery executando o 8e versão 2. Posso autenticar usuários no AD usando a configuração do LDAP, mas só posso fazê-lo funcionar se não usar SSL / TLS e somente se eu use a autenticação SIMPLE. No momento, ele está sendo autenticado usando um usuário de baixo impacto, mas também é o único sistema em nossa rede que não usa LDAPS.

Eu posso obter informações do AD sobre LDAPS usando o ldp.exe da minha máquina, nosso firewall, nosso filtro de e-mail, nossas caixas de linux, etc. O único problema é o Fiery.

Adicionei o certificado do servidor LDAP como um certificado confiável ao Fiery, mas depois de marcar a caixa de Comunicação segura e alterar a porta para 636, pressione Validar resultados em uma caixa de diálogo que diz: Servidor de falha na validação do LDAP Nome inválido ou servidor indisponível.

Eu tentei alterar o nome do servidor para usar apenas o nome, o FQDN e o endereço IP e alterá-lo para outro servidor, apenas para ver se era apenas esse servidor AD que era exigente com o Fiery.

EDIT: saída LDP removida, análise de captura de pacotes adicionada do wireshark: A conversa parece bastante normal para mim, até o ponto em que o Fiery encerra a conexão depois que o servidor envia de volta uma resposta de handshake. Talvez eles tenham atrapalhado sua implementação de TLS? Eu estou tentando apoio, mas tem sido bastante inútil até agora. O certificado é um certificado SHA-2 (sha256RSA) de 2048 bits. Além disso, parece que o Fiery está especificando o TLS 1.0. Analisando o link , não estou vendo A combinação SHA256 e TLS 1.0 é suportada pelo SChannel. headdesk talvez por isso, após o DC alterar a especificação de criptografia, a conexão é encerrada pelo Fiery? O TLS 1.1 e 1.2 estão ativados no DC.

Conversa do 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

EDIT: revisamos esse problema depois que o patch recente de SCHANNEL e o POODLE solicitaram a alteração do nosso gerenciamento de codificação, e ainda estou tendo esse problema.

EDIT: endereçando a resposta do @ DTK: CA raiz adicionada já. Readded para testar. O DC FQDN sendo usado, cert corresponde ao FQDN, resolve corretamente no DNS. O cliente pode acessar o DC usando o LDAP bem. Outros clientes alcançam o LDAPS no mesmo DC muito bem. DC suporta TLS 1.0, 1.1 e 1.2. Usando autenticação simples. Chave pública é RSA 2048 bit assinado com SHA256.

Aqui estão as cifras com suporte na ordem de criptografia para SCHANNEL de HKLM \ SOFTWARE \ Políticas \ Microsoft \ Criptografia \ Configuração \ SSL \ 00010002:

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

    

Answer 1

Você precisa ter todos os itens a seguir para o LDAPS funcionar:

• Configure o cliente para confiar na CA que emitiu o certificado (ou, se estiver usando uma PKI hierárquica, a CA raiz)
• Configure o cliente para acessar o servidor do Controlador de Domínio via FQDN
• O FQDN do servidor do Controlador de Domínio deve ser resolvido corretamente no DNS
• O FQDN do servidor do Controlador de domínio configurado no cliente deve corresponder ao SubjectCN no certificado usado para o TLS OR deve corresponder a uma das entradas no SubjectAlternativeName no certificado usado para o TLS
• Se o dispositivo cliente não usar o Kerberos (e especificamente um Kerberos compatível com AD), você deve usar o Simple Auth
  • O SASL não funcionará e a tentativa de usá-lo será ABEND com uma mensagem de erro não útil
• O cliente e o servidor devem suportar um conjunto comum de Versões TLS Protocol (Preferencialmente TLS 1.1 ou posterior) e um conjunto comum de algoritmos (Key Exchange, Autenticação, Cifra de Chave Simétrica e Hash / MAC)
  • KEX: RSA, DHE, ECDHE
  • AuthN: RSA, DSA, ECDSA
  • Cifra: AES-CBC, AES-GCM (oh queridos deuses, não RC4, DES ou 3DES)
  • Hash: SHA, SHA256 / 384/512 (favor, por favor, não MD2 ou MD5)
• O cliente e o servidor devem oferecer suporte a comprimentos de chave comuns
  • RSA: comprimento de chave pública de 2048 bits ou 4096 bits
  • DSA: comprimento de chave pública de 2048 bits (se suportado; muitos suportam apenas chaves de 1024 bits)
  • ECDSA / ECDHE: 283 bits ou mais, com base no link
  • AES: 128 bits ou mais
  • SHA *: 256 bits ou mais de tamanho de bloco / digest-length

Answer 2

O Fiery não precisa confiar no certificado do servidor LDAP diretamente. Deve estar confiando na CA ou cadeia de CAs que assinaram o certificado do servidor LDAP.

Além disso, o certificado do servidor LDAP contém referências a um local de verificação da CRL ou ao servidor OSCP? E, em caso afirmativo, a conectividade de rede do Fiery tem acesso a esse (s) local (is)? O certificado pode ser válido, mas o Fiery pode não conseguir verificar corretamente se ele não foi revogado.

Outra coisa (incomum) que pode estar acontecendo é se o Fiery estiver sufocando em algo como o tamanho da chave do certificado.