Eu acho que você poderia atacar isso de duas maneiras: fazendo com que o cliente ldapsearch trabalhe usando seus certificados existentes ou gerando novos certificados de que goste. Pessoalmente, eu imagino que modificar o seu certificado de servidor seja mais fácil do que mudar o código ldapsearch , então é isso que eu olhei.
O erro acima sugere que algo está faltando no seu certificado do lado do servidor (ou seja, o cliente não quer falar com o seu servidor porque ele não está se identificando corretamente).
Para iniciantes, examinei o certificado usado por um servidor LDAP aleatório, neste caso directory.washington.edu . Se você não conseguir seu certificado, por exemplo:
openssl s_client -connect directory.washington.edu:636 > dirwash.crt
e faça:
openssl x509 -in dirwash.crt -text
você verá:
X509v3 Key Usage:
Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment
X509v3 Extended Key Usage:
TLS Web Client Authentication, TLS Web Server Authentication
Outros servidores LDAP (por exemplo, ldap.virginia.edu ) não possuem essas extensões. Outros, como ldap.itd.umich.edu , têm uma variação dos itens acima:
X509v3 Key Usage:
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
Em suma, sugiro que você verifique seu certificado de servidor - publique-o aqui, se quiser - para ver se ele contém X509v3 (Extended) Key Usage extensions e, em caso afirmativo, se eles são semelhantes àqueles em uso em outros servidores LDAP.
Eu vi um tópico de e-mail que sugeriu que: (1) as extensões devem estar ausentes; ou (2) se as extensões estiverem presentes, elas precisam conter pelo menos TLS Web Server Authentication . Eu não sei se isso é verdade neste caso, mas algo a considerar de qualquer maneira.