CentOS openLDAP cert questions de confiance

# 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 certificatee 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) --- 

openssl semble penser que le certificate est bien, mais les bibliothèques d' openldap ( pam_ldap présentent un comportement similaire, c'est à ce sujet que je suis arrivé à ce désordre) sont en désaccord.
Qu'est-ce que je fais mal?

5 Solutions collect form web for “CentOS openLDAP cert questions de confiance”

RHEL ne fournit en rien tout ce qui peut être utilisé comme un «directory de certificates» aux fins de la confiance de l'AC. Pour OpenSSL, un directory de certificates – un «CApath» – est un directory contenant des files de certificates individuels (au format PEM ou au format «certificate approuvé» de OpenSSL), avec des noms dans un format spécifique basé sur un hachage du nom du sujet du certificate. Habituellement, cela est réalisé en mettant des files avec des noms lisibles par l'homme et des extensions .pem dans un directory et en exécutant c_rehash (voir man c_rehash ). Pour GnuTLS depuis 3.3.6 (avant que GnuTLS n'avaient aucun support d'annuaire), il ne s'agit que d'un directory contenant des files PEM; GnuTLS tentera de charger tous les files dans le directory et réussira sur tout ce que PEM-ish (il ne peut pas gérer le format «certificate approuvé» d'OpenSSL). Je ne suis pas vraiment sûr de savoir si NSS peut effectivement utiliser un directory plein de files de certificates individuels en tant que racine de confiance, mais la documentation d'OpenLDAP semble suggérer qu'il peut (mais si le directory contient également une database NSS, il donnera cette priorité). Quoi qu'il en soit, RHEL n'a rien à voir avec un directory plein de files de certificates CA individuels.

Debian et les dérivés fournissent /etc/ssl/certs dans ce format; /etc/ssl/certs est l'location de la boutique de confiance canonique sur Debian, et IMO tout ce qui le fournit devrait essentiellement l'établir comme Debian, car Debian avait ce directory réparé plus ou less de la même manière depuis 1999. RHEL a un /etc/ssl/certs , mais il n'est pas dans ce format – il ne contient aucun file de certificate individuel. Vous ne pouvez pas l'utiliser comme CApath. Honnêtement, sur RHEL (et Fedora, et dérivés), ce directory est essentiellement 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=1053882 pour un aperçu de la raison pour laquelle il existe en premier lieu, et comment j'essaie de le réparer). Donc, je pense que vous avez raison de savoir ce qui se passe, mais mal sur la raison pour laquelle. OpenLDAP ne fait rien de mal, et ce n'est pas en panne car "ca-bundle.trust.crt … est une database de cert / key de Mozilla NSS" (ceux sont appelés cert8/9.db et key3/4.db , et les systèmes de RHEL en direct dans /etc/pki/nssdb ), c'est juste parce que /etc/ssl/certs n'est pas utilisable comme un «directory de certificates».

RHEL ne fournit rien d'autre utilisable en tant que magasin de confiance CApath-style ailleurs. Le magasin de confiance système de RHEL est fourni sous la forme d'un seul file PEM (un «file CA» dans les termes OpenSSL), qui se trouve à /etc/pki/tls/certs/ca-bundle.crt et /etc/pki/tls/cert.pem . Il se trouve également dans /etc/ssl/certs/ca-bundle.crt comme /etc/ssl/certs est en fait juste un lien symbolique vers /etc/pki/tls/certs , mais cet location n'est pas canonique et ne devrait vraiment pas ' être utilisé par n'importe quoi. RHEL fournit également un lot dans le format «certificate approuvé» d' /etc/pki/tls/certs/ca-bundle.trust.crt sous la forme /etc/pki/tls/certs/ca-bundle.trust.crt .

La bonne chose à faire, comme vous l'avez compris, consiste à utiliser le file groupé que le système fournit. Votre réponse fonctionnera, mais pour les raisons mentionnées ci-dessus, je vous recommand vivement TLS_CACERT=/etc/pki/tls/certs/ca-bundle.crt ou TLS_CACERT=/etc/pki/tls/cert.pem sur TLS_CACERT=/etc/ssl/certs/ca-bundle.crt .

(Il n'y a rien de nouveau à distance dans tout cela, mais la confusion sur les interwebs est répandue. RH et les dérivés n'ont jamais fourni un directory complet de certificates jamais. Ils ont fourni un file group depuis l'an 2000. Il était est passé de / usr / share / ssl à / etc / pki / tls en 2005. Debian a eu les deux /etc/ssl/certs tant que directory CApath-style et /etc/ssl/certs/ca-certificatees.crt tant que package plus ou less depuis l'âge de la pierre.)

/etc/ssl/certs/ contient /etc/ssl/certs/ca-bundle.trust.crt dans le cadre de ca-certificatees-2010.63-3.el6_1.5.noarch , qui est une database de cert / key de Mozilla NSS. L'inclusion de ce file dans TLS_CACERTDIR provoque l' TLS_CACERTDIR tous les autres files.

TLS_CACERTDIR
Spécifie le path d'access d'un directory contenant des certificates d'autorité de certificateion dans des files individuels distincts. Le TLS_CACERT est toujours utilisé avant TLS_CACERTDIR.` Ce paramètre est ignoré par GnuTLS.

Lors de l'utilisation de Mozilla NSS, peut contenir une database CERt / key de Mozilla NSS. Si contient une database de cert / key de Mozilla NSS et des files cert CA, OpenLDAP utilisera la database cert / key et ignorera les files Cert CA.

Cependant, openldap-2.4.23-26.el6_3.2.i686 ne semble pas traiter correctement.

Réponse courte
Utilisez LDAPTLS_CACERT=/etc/ssl/certs/ca-bundle.crt
(file de configuration TLS_CACERT=/etc/ssl/certs/ca-bundle.crt )
Ce file est également fourni par ca-certificatees-2010.63-3.el6_1.5.noarch .

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

Les premiers clones RHEL ont deux files ldap.conf , /etc/ldap.conf ou dans RHEL6 is est obsolète, mais vous pouvez utiliser /etc/nslcd.conf pour l' authentification maintenant /etc/openldap/ldap.conf est uniquement pour les requêtes , donc ldapsearch , ldapmodify , ldapremove , c'est vraiment votre profil afin que vous ne deviez pas avoir une string longue méchante à chaque fois que vous souhaitez exécuter une command ldap.

Maintenant, avec cela en dehors, vous avez deux parameters,

  • tls_cacertfile – définissez explicitement le ca cert et vous devriez être tls_cacertfile à aller
  • tls_cacertdir – déposez le ca cert dans le directory, mais cela ne fonctionnera pas, car il doit être haché …

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

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

Espérons que cela arrange les choses.

Quelqu'un d'autre se heurte à cela; C'est ce qui m'a fonctionné sur centos 6 openldap et sssd:

notes: a. Certains "smart guy" ont décidé de faire en sorte que sssd exige TLS / SSL; changement de comportement de centos5; Ceci est idéal pour les systèmes externes; mais lorsque vous avez 300 nœuds sur un appareil interne avec un réseau interne inaccessible au groupe de machines; C'est une fonctionnalité de security extrêmement inutile.

b. En outre, les certificates auto-sélectionnés ne semblent plus fonctionner; continuera à essayer

c. Évitez NSLCD à tout prix; était en proie à des problèmes sans interruption lorsque j'ai configuré le drapeau hérité et utilisé à la place de sssd (netgroups, deadloging syslog, etc.).

Pour se lancer en utilisant 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 

Selon la page de chaque page que j'ai vu (mais je ne suis pas un user de CentOS), il n'y a pas de LDAPTLS_CACERTDIR . La variable correcte à définir est TLS_CACERTDIR . Vous devez le définir définitivement dans /etc/openldap/ldap.conf ou partout où CentOS conserve le file de configuration de la bibliothèque LDAP. En outre, vous devrez peut-être configurer pam-ldap lui-même pour searchr les certificates de CA. Dans CentOS, c'est /etc/pam_ldap.conf , je pense, et la variable à définir est tls_cacertdir .

  • OpenSSL Aucun certificate client présenté (SMTP, Postfix)
  • Le server IIS 8.5 n'accepte pas une connection TLS 1.0 à partir de Windows Server 2003
  • Postfix et OpenSSL: "Impossible d'get un certificate émetteur local"
  • Utilisation de TLS 1.2 et java 6
  • VPN Security Versus Plain Vieux TLS
  • Postfix obligatoire smtp / smtpd vs "non obligatoire" différence et configuration
  • ProFTPD - Impossible de récupérer la liste des répertoires lors de l'utilisation de TLS
  • Certificat SSL Nginx servi pour tous les noms de server afin de résoudre l'IP du server
  • Les astuces du serveur de linux et windows, tels que ubuntu, centos, apache, nginx, debian et des sujets de rĂ©seau.