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 ldaps avec mon serveur Novel eDirectory 8.8, je dois parfois mettre TLS_REQCERT neverle 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-certificate ldap edirectory

— David R.
source

"Impossible de contacter le serveur LDAP" sonne plus comme si le serveur n'était tout simplement pas accessible depuis cette machine cliente. Avez-vous d'abord vérifié que vous pouvez vous y connecter? Par exemple telnet ldapserver ldapsou openssl s_client -connect ldapserver:636.

— Richard E. Silverman

Oui, j'ai confirmé qu'il peut se connecter au serveur. Après tout, cela ne fonctionnerait jamais du tout s'il ne pouvait pas se connecter du tout.

— David R.

Vous avez mentionné trois hôtes clients différents. Celui qui ne fonctionne pas n'a peut-être pas pu se connecter en raison d'un problème de réseau alors que les autres l'ont pu.

— Richard E. Silverman

Je pensais que mon message était assez clair que je modifiais le fichier ldap.conf sur tous les hôtes. Comme lorsque j'ai ajouté la ligne au fichier, cela a fonctionné, mais sans la ligne, cela n'a pas fonctionné. Ainsi, pas un problème de connexion.

— David R.

Ce n'était pas clair pour moi lorsque j'ai lu votre message au départ, bien que je vois ce que vous voulez dire maintenant. Quoi qu'il en soit, les informations de débogage TLS que vous avez ajoutées montrent le problème; J'ai ajouté une réponse pour assurer le suivi.

— Richard E. Silverman

Réponses:

ldapsearch recherche dans / etc / openldap / cacerts son magasin de certificats CA de confiance, 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 exemple par le programme "Hathconfig" de Red Hat, ou d'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).

— Richard E. Silverman
source

Ah. /etc/openldap/certsest l'endroit où se trouve le magasin de certificats. Pas des cacerts. Dans /etc/openldap/ldap.conf, je suis passé TLS_CACERTDIR /etc/openldap/cacertsà TLS_CACERTDIR /etc/openldap/certset ma commande ldapsearch a commencé à fonctionner. Merci!

— David R.

J'ai installé ldapsearch sur Ubuntu 16.04, et il n'y a pas de répertoire / etc / openldap.

— vcardillo

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

— Andrew Schulman
source

J'ai modifié ma question en réponse à votre suggestion. Merci!

— David R.

La solution dépend de votre installation:

Si vous utilisez un certificat non valide , vous pouvez forcer son acceptation à configurer /etc/openldap/ldap.confavec
```
TLS_REQCERT allow
```
ou
```
TLS_REQCERT never
```
Si vous utilisez un certificat valide, votre installation LDAP ne sait probablement 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.confavec
```
TLS_CACERT /etc/openldap/cacert
TLS_REQCERT demand
```
/etc/openldap/cacertpeut être ceci ou être situé 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/ldapou environ /etc/openldap.

— Juan Garcia
source