CentOS openLDAP cert trust issues

# LDAPTLS_CACERTDIR=/etc/ssl/certs/ ldapwhoami -x -ZZ -H ldaps://ldap.domain.tld
ldap_start_tls: Can't contact LDAP server (-1)
      additional info: TLS error -8172:Peer's certificate issuer has been marked as not trusted by the user.

# openssl s_client -connect ldap.domain.tld:636 -CApath /etc/ssl/certs
<... successful tls negotiation stuff ...>
    Compression: 1 (zlib compression)
    Start Time: 1349994779
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---

opensslsemble penser que le certificat est bien, mais openldaples bibliothèques de ( pam_ldapprésentent un comportement similaire, c'est ainsi que je suis arrivé à ce bordel) ne sont pas d'accord.
Qu'est-ce que je fais mal?

RHEL ne fournit en fait rien qui puisse être utilisé comme «répertoire de certificats» à des fins d'approbation par l'autorité de certification. Pour OpenSSL, un répertoire de certificats - un `` CApath '' - est un répertoire contenant des fichiers de certificats individuels (au format PEM ou au format étendu de `` certificat de confiance '' d'OpenSSL), avec des noms dans un format spécifique basé sur un hachage du nom de sujet du certificat. Habituellement, cela est réalisé en plaçant des fichiers avec des noms et des .pemextensions lisibles par l'homme dans un répertoire et en les exécutant c_rehash(voirman c_rehash). Pour GnuTLS depuis la 3.3.6 (avant cela, GnuTLS n'avait pas de support de répertoire), c'est juste un répertoire contenant des fichiers PEM; GnuTLS essaiera de charger chaque fichier dans le répertoire et réussira sur tout ce qui est PEM (il ne peut pas gérer le format de «certificat de confiance» d'OpenSSL). Je ne suis pas honnêtement sûr si NSS peut réellement utiliser un répertoire plein de fichiers de certificats individuels comme racine de confiance, mais la documentation d'OpenLDAP semble suggérer que cela peut (mais si le répertoire contient également une base de données NSS, il donnera cette priorité). Quoi qu'il en soit, RHEL n'a rien de tel qu'un répertoire rempli de fichiers de certificats d'autorité de certification individuels.

Debian et ses dérivés fournissent /etc/ssl/certsdans ce format; /etc/ssl/certsest l'emplacement canonique du magasin de confiance sur Debian, et IMO tout ce qui le fournit devrait essentiellement le présenter comme Debian, car Debian avait ce répertoire disposé plus ou moins de la même manière depuis 1999. RHEL a un /etc/ssl/certsrépertoire, mais il est dans pas dans ce format - il ne contient aucun fichier de certificat individuel. Vous ne pouvez pas l'utiliser comme CApath. Honnêtement, sur RHEL (et Fedora et dérivés), ce répertoire est fondamentalement un piège. Ne l'utilisez pas. (Voir https://bugzilla.redhat.com/show_bug.cgi?id=572725 et https://bugzilla.redhat.com/show_bug.cgi?id=1053882pour quelques informations sur pourquoi il existe en premier lieu et comment j'essaye de le réparer). Je pense donc que vous avez raison sur ce qui se passe, mais que vous avez tort sur la raison. OpenLDAP ne fait rien de mal, et il n'échoue pas car "ca-bundle.trust.crt ... est une base de données de clés / certificats Mozilla NSS" (celles-ci sont appelées cert8/9.dbet key3/4.db, et celles du système sur RHEL en direct /etc/pki/nssdb) , il échoue simplement car il /etc/ssl/certsn'est pas du tout utilisable comme «répertoire de certificats».

RHEL ne fournit rien non plus utilisable comme magasin de confiance de style CApath ailleurs. Le magasin de confiance système de RHEL est fourni sous la forme d'un fichier de bundle PEM unique (un «fichier CA» en termes OpenSSL), qui peut être trouvé sur /etc/pki/tls/certs/ca-bundle.crtet /etc/pki/tls/cert.pem. Il peut également être trouvé sur /etc/ssl/certs/ca-bundle.crtas /etc/ssl/certsis en fait juste un lien symbolique vers /etc/pki/tls/certs, mais cet emplacement n'est pas canonique et ne devrait vraiment être utilisé par rien. RHEL fournit également un bundle au format «certificat de confiance» d'OpenSSL /etc/pki/tls/certs/ca-bundle.trust.crt.

La bonne chose à faire, comme vous l'avez compris, est d'utiliser le fichier de bundle fourni par le système. Votre réponse fonctionnera, mais pour les raisons mentionnées ci-dessus, je recommanderais fortement TLS_CACERT=/etc/pki/tls/certs/ca-bundle.crtou TLS_CACERT=/etc/pki/tls/cert.pemplus TLS_CACERT=/etc/ssl/certs/ca-bundle.crt.

(Il n'y a rien de nouveau à distance dans tout cela, btw, mais la confusion sur les interwebs est répandue. RH et dérivés n'ont jamais fourni un répertoire complet de certificats, jamais. Ils ont fourni un fichier de paquet depuis l'an 2000. Il était déplacé de / usr / share / ssl vers / etc / pki / tls en 2005. Debian a eu à la fois /etc/ssl/certsun répertoire de style CApath et /etc/ssl/certs/ca-certificates.crtun fichier de bundle plus ou moins depuis l'âge de pierre.)

/etc/ssl/certs/contient /etc/ssl/certs/ca-bundle.trust.crtdans le cadre de ca-certificates-2010.63-3.el6_1.5.noarch, qui est une base de données de certificats / clés Mozilla NSS. L'inclusion de ce fichier dans TLS_CACERTDIRentraîne l'ignorance de tous les autres fichiers.

TLS_CACERTDIR
Spécifie le chemin d'un répertoire qui contient les certificats d'autorité de certification dans des fichiers individuels séparés. TLS_CACERT est toujours utilisé avant TLS_CACERTDIR. »Ce paramètre est ignoré avec GnuTLS.

Lors de l'utilisation de Mozilla NSS, peut contenir une base de données de clés / certificats Mozilla NSS. S'il contient une base de données de certificats / clés Mozilla NSS et des fichiers de certificats CA, OpenLDAP utilisera la base de données de certificats / clés et ignorera les fichiers de certificats CA. »

Cependant, openldap-2.4.23-26.el6_3.2.i686ne semble pas gérer cela correctement.

Utilisation à réponse courteLDAPTLS_CACERT=/etc/ssl/certs/ca-bundle.crt
(fichier de configuration TLS_CACERT=/etc/ssl/certs/ca-bundle.crt)
Ce fichier est également fourni par ca-certificates-2010.63-3.el6_1.5.noarch.

N'importe qui d'autre se heurte à cela; c'est ce qui a fonctionné pour moi sur centos 6 openldap et sssd:

notes: a. Un "type intelligent" a décidé de faire en sorte que sssd nécessite TLS / SSL; changement de comportement de centos5; c'est génial pour les systèmes externes; mais lorsque vous avez plus de 300 nœuds sur l'appliance interne avec un réseau interne inaccessible au cluster de machines; c'est une fonction de sécurité extrêmement inutile.

b. De plus, les certificats auto-interprétés ne semblent plus fonctionner; continuera d'essayer

c. Évitez NSLCD à tout prix; a été en proie à des problèmes non-stop lorsque j'ai défini le drapeau hérité et utilisé à la place de sssd (netgroups; blocage de syslog, etc.).

Pour être opérationnel avec sssd;

1. sssd.conf

   [domain/default]
   ldap_id_use_start_tls = True
   id_provider = ldap
   auth_provider = ldap
   chpass_provider = ldap
   cache_credentials = True
   ldap_search_base = dc=local
   enumerate = True
   ldap_uri = ldap://192.168.1.2/
   ldap_tls_cacertdir = /etc/openldap/cacerts
   ldap_tls_reqcert = allow
   ldap_schema = rfc2307bis
   

2. slapd.conf

   TLSCACertificateFile   /etc/openldap/cacerts/ca-bundle.crt
   TLSCertificateFile      /etc/openldap/cacerts/slapd.pem
   TLSCertificateKeyFile   /etc/openldap/cacerts/slapd.pem
   TLSCipherSuite HIGH:MEDIUM:-SSLv2
   

3. ldap.conf

   URI ldap://192.168.1.2/
   BASE dc=local
   
   TLS_CACERTDIR /etc/openldap/cacerts
   

C'est un problème très courant, ne vous inquiétez pas, j'ai une réponse pour vous.

Premières RHEL Clones ont avoir deux ldap.conffichiers, /etc/ldap.confou RHEL6 est est obsolète mais vous pouvez utiliser /etc/nslcd.confpour l' authentification maintenant /etc/openldap/ldap.confest seulement pour les requêtes , donc ldapsearch, ldapmodify, ldapremove, ce qui est vraiment votre profil afin que vous ne devez pas avoir une chaîne méchante longue chaque fois que vous voulez pour exécuter une commande ldap.

Maintenant, avec cela à l'écart, vous avez deux paramètres,

• tls_cacertfile - définir explicitement le ca cert et vous devriez être prêt à partir
• tls_cacertdir- déposez le certificat CA dans le répertoire mais cela ne fonctionnera pas, car il doit être haché ...

utiliser openssl x509 -hash -noout -in $file , ln -s $file $file.0, votre certificat CA fonctionnera.

Notez également que si le fichier de configuration est en CAPS, vous travaillez dans /etc/openldap/ldap.conf, ce sont des fichiers très différents.

Espérons que cela arrange les choses.

Selon chaque page de manuel que j'ai vue (mais je ne suis pas un utilisateur CentOS), il n'y a rien de tel LDAPTLS_CACERTDIR. La variable correcte à définir est TLS_CACERTDIR. Vous devez le définir de manière permanente dans /etc/openldap/ldap.confou partout où CentOS conserve le fichier de configuration de la bibliothèque LDAP. En outre, vous devrez peut-être configurer pam-ldap lui-même pour rechercher les certificats CA. Dans CentOS /etc/pam_ldap.conf, c'est , je pense, et la variable à définir est tls_cacertdir.