web-dev-qa-db-fra.com

Certains systèmes ne peuvent pas se connecter à LDAP via LDAP, mais d'autres le peuvent, est-ce le certificat générique?

Lorsque j'essaie d'établir des connexions LDAP avec mon serveur Novel eDirectory 8.8, je dois parfois mettre TLS_REQCERT never dans le fichier ldap.conf des serveurs clients. De toute évidence, c'est une mauvaise idée.

La commande que j'exécute est quelque chose comme ça avec des informations d'identification qui fonctionnent réellement ...

ldapsearch -x -H ldaps://ldapserver -b 'ou=active,ou=people,dc=example,dc=org' -D 'cn=admin,dc=example,dc=org' -W "cn=username"

Sur Ubuntu 13.10, cela fonctionne bien.

Sur SLES, cela fonctionne bien.

Sur CentOS 6.5, il renvoie:

ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)

Maintenant, le certificat que j'ai importé est un certificat générique acheté auprès de DigiCert. Mon collègue a trouvé des rapports indiquant que certains systèmes ont des problèmes avec les caractères génériques.

Alors, le certificat générique est-il à blâmer? Si oui, comment puis-je le réparer?

Si ce n'est pas le certificat générique, alors qu'est-ce que c'est?

Suite à la suggestion d'Andrew Schulman, j'ai ajouté -d1 à ma commande ldapsearch. Voici ce que j'ai fini avec:

ldap_url_parse_ext(ldaps://ldap.example.org)
ldap_create
ldap_url_parse_ext(ldaps://ldap.example.org:636/??base)
Enter LDAP Password: 
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_Host: TCP ldap.example.org:636
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_Host: Trying 10.225.0.24:636
ldap_pvt_connect: fd: 3 tm: -1 async: 0
TLS: certdb config: configDir='/etc/openldap' tokenDescription='ldap(0)' certPrefix='cacerts' keyPrefix='cacerts' flags=readOnly
TLS: cannot open certdb '/etc/openldap', error -8018:Unknown PKCS #11 error.
TLS: could not get info about the CA certificate directory /etc/openldap/cacerts - error -5950:File not found.
TLS: certificate [CN=DigiCert High Assurance EV Root CA,OU=www.digicert.com,O=DigiCert Inc,C=US] is not valid - error -8172:Peer's certificate issuer has been marked as not trusted by the user..
TLS: error: connect - force handshake failure: errno 2 - moznss error -8172
TLS: can't connect: TLS error -8172:Peer's certificate issuer has been marked as not trusted by the user..
ldap_err2string
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)

D'après ce que cela dit, CentOS ne fait pas confiance à DigiCert? Ou CentOS n'a pas de liste d'émetteurs de confiance?

ssl-certificateldapedirectory
15
David R.

ldapsearch recherche dans/etc/openldap/cacerts son magasin de certificats de CA approuvés, et cela n'est apparemment pas configuré, et donc il rejette le certificat car il ne peut pas construire une chaîne de confiance pour lui. Si ldapsearch utilisait OpenSSL, il aurait besoin d'une collection de format "hashdir" telle que produite par ex. le programme Red Hat "authconfig" ou un fichier unique avec une liste plate de certificats de confiance. La référence ici à "moznss" suggère que cette ldapsearch est construite contre Mozilla NSS, auquel cas vous devez utiliser "certutil" pour créer le cert db (ou mieux, pointez-le vers le magasin de certificats NSS système, s'il y en a un) .

Sur les systèmes où cela fonctionne, ldapsearch doit avoir un magasin de certificats fonctionnel, peut-être parce que ces packages OpenLDAP sont plutôt construits avec OpenSSL (ou peut-être y a-t-il un magasin de style NSS fonctionnel).

9
Richard E. Silverman

ldapsearch dira "Impossible de contacter le serveur LDAP" s'il ne peut pas vérifier le certificat TLS. Ajouter -d1 à votre commande ldapsearch et vérifiez les lignes de sortie qui commencent par "TLS:" pour obtenir plus d'informations sur l'échec de la connexion TLS et pourquoi.

13
Andrew Schulman

La solution dépend de votre installation:

  • Si vous êtes en utilisant un cert non valide, vous pouvez forcer l'accepter en configurant /etc/openldap/ldap.conf avec

    TLS_REQCERT allow

    ou

    TLS_REQCERT never

  • Si vous êtes en utilisant un certificat valide probablement votre installation LDAP ne sait pas où se trouve le magasin de certificats CA de confiance (probablement en fonction de votre installation OpenSSL). Ensuite, vous pouvez essayer de définir son emplacement et forcer la configuration de la vérification /etc/openldap/ldap.conf avec

    TLS_CACERT /etc/openldap/cacert
TLS_REQCERT demand

    /etc/openldap/cacert peut être ceci ou être localisé dans n'importe quel chemin. Il doit contenir la chaîne de certificats de votre autorité de certification. Il peut s'agir d'un fichier unique avec une liste plate de certificats approuvés.

Les chemins de note dépendent du fournisseur LDAP. Il pourrait être /etc/ldap ou /etc/openldap ou plus.

8
Juan Garcia