Vertrauensprobleme mit CentOS openLDAP cert

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

opensslscheint zu denken, dass das Zertifikat in Ordnung ist, aber openldapdie Bibliotheken (zeigen ein pam_ldapähnliches Verhalten, wie ich zu diesem Durcheinander gekommen bin) stimmen nicht überein.
Was mache ich falsch?

RHEL bietet in der Tat nichts an, was als "Zertifikatverzeichnis" für CA-Vertrauenszwecke verwendet werden könnte. Bei OpenSSL ist ein Zertifikatverzeichnis - ein "CApath" - ein Verzeichnis, das einzelne Zertifikatdateien (im PEM-Format oder im erweiterten "Trusted Certificate" -Format von OpenSSL) mit Namen in einem bestimmten Format enthält, das auf einem Hash des Antragstellernamens des Zertifikats basiert. In der Regel wird dies erreicht, indem Dateien mit lesbaren Namen und .pemErweiterungen in ein Verzeichnis gestellt und darauf ausgeführt werden c_rehash(sieheman c_rehash). Bei GnuTLS seit 3.3.6 (GnuTLS hatte zuvor keine Verzeichnisunterstützung) handelt es sich lediglich um ein Verzeichnis mit PEM-Dateien. GnuTLS wird versuchen, jede Datei im Verzeichnis zu laden und auf PEMs erfolgreich zu sein (es kann nicht mit OpenSSLs 'Trusted Certificate'-Format umgehen). Ich bin mir ehrlich gesagt nicht sicher, ob NSS tatsächlich ein Verzeichnis mit einzelnen Zertifikatdateien als Vertrauensstamm verwenden kann, aber die OpenLDAP-Dokumentation scheint dies zu empfehlen (aber wenn das Verzeichnis auch eine NSS-Datenbank enthält, wird diese Priorität zugewiesen). Unabhängig davon verfügt RHEL nicht über ein Verzeichnis mit einzelnen CA-Zertifikatdateien.

Debian und Derivate liefern /etc/ssl/certsin diesem Format; /etc/ssl/certsist der kanonische Vertrauensspeicherort auf Debian, und alles, was IMO anbietet, sollte im Grunde genommen so aussehen wie Debian, da Debian dieses Verzeichnis seit 1999 mehr oder weniger auf die gleiche Weise angelegt hat. RHEL hat ein /etc/ssl/certsVerzeichnis, aber es befindet sich in nicht in diesem Format - es enthält überhaupt keine einzelnen Zertifikatdateien. Sie können es nicht als CApath verwenden. Ehrlich gesagt ist dieses Verzeichnis bei RHEL (und Fedora und Derivaten) im Grunde genommen eine Falle. Benutze es nicht. (Siehe https://bugzilla.redhat.com/show_bug.cgi?id=572725 und https://bugzilla.redhat.com/show_bug.cgi?id=1053882für einige Hintergrundinformationen darüber, warum es überhaupt existiert und wie ich versuche, es zu reparieren). Ich denke, Sie haben Recht mit dem, was vor sich geht, aber Sie haben Unrecht mit dem Grund, warum. OpenLDAP macht nichts falsch und es schlägt auch nicht fehl, weil "ca-bundle.trust.crt ... eine Mozilla NSS-Zertifikats- / Schlüsseldatenbank" ist (diese heißen cert8/9.dbund key3/4.dbund die systemweiten auf RHEL leben in /etc/pki/nssdb). , es scheitert nur daran, dass /etc/ssl/certses überhaupt nicht als 'Zertifikatsverzeichnis' verwendet werden kann.

RHEL bietet auch sonst nirgendwo etwas, das als CApath-artiger Truststore verwendet werden kann. Der System Trust Store von RHEL wird als einzelne PEM-Bundle-Datei (eine 'CA-Datei' in OpenSSL-Begriffen) bereitgestellt, die unter /etc/pki/tls/certs/ca-bundle.crtund abgerufen werden kann /etc/pki/tls/cert.pem. Es kann auch unter gefunden werden, /etc/ssl/certs/ca-bundle.crtda /etc/ssl/certses eigentlich nur ein Symlink zu ist /etc/pki/tls/certs, aber dieser Ort ist nicht kanonisch und sollte wirklich nie von irgendetwas benutzt werden. RHEL bietet auch ein Paket im OpenSSL-Format 'Trusted Certificate' als an /etc/pki/tls/certs/ca-bundle.trust.crt.

Wie Sie herausgefunden haben, müssen Sie die Bundle-Datei verwenden, die das System zur Verfügung stellt. Ihre Antwort wird funktionieren, aber aus den oben genannten Gründen würde ich dringend empfehlen TLS_CACERT=/etc/pki/tls/certs/ca-bundle.crtoder TLS_CACERT=/etc/pki/tls/cert.pemüber TLS_CACERT=/etc/ssl/certs/ca-bundle.crt.

(Übrigens gibt es in alledem nichts Neues, aber Verwirrung in den Interwebs ist weit verbreitet. RH und Derivate haben noch nie ein Verzeichnis voller Zertifikate bereitgestellt. Sie haben seit dem Jahr 2000 eine Bundle-Datei bereitgestellt. Dies war es bewegt von / usr / share / ssl / etc / pki / tls 2005 Debian beide hatte /etc/ssl/certsals capath-style - Verzeichnis und /etc/ssl/certs/ca-certificates.crtals Bundle - Datei mehr oder weniger seit der Steinzeit.)

/etc/ssl/certs/enthält /etc/ssl/certs/ca-bundle.trust.crtals Teil von ca-certificates-2010.63-3.el6_1.5.noarch, welches eine Mozilla NSS Zertifikat / Schlüsseldatenbank ist. Das Einschließen dieser Datei in TLS_CACERTDIRbewirkt, dass alle anderen Dateien ignoriert werden.

TLS_CACERTDIR
Gibt den Pfad eines Verzeichnisses an, das Zertifizierungsstellenzertifikate in separaten Einzeldateien enthält. TLS_CACERT wird immer vor TLS_CACERTDIR verwendet. Dieser Parameter wird bei GnuTLS ignoriert.

Enthält bei Verwendung von Mozilla NSS möglicherweise eine Mozilla NSS-Zertifikats- / Schlüsseldatenbank. Wenn OpenLDAP eine Mozilla NSS-Zertifizierungs- / Schlüsseldatenbank und CA-Zertifizierungsdateien enthält, verwendet OpenLDAP die Zertifizierungs- / Schlüsseldatenbank und ignoriert die CA-Zertifizierungsdateien. "

Scheint openldap-2.4.23-26.el6_3.2.i686jedoch nicht richtig damit umzugehen.

Short Answer
Use LDAPTLS_CACERT=/etc/ssl/certs/ca-bundle.crt
(Konfigurationsdatei TLS_CACERT=/etc/ssl/certs/ca-bundle.crt)
Diese Datei wird auch von bereitgestellt ca-certificates-2010.63-3.el6_1.5.noarch.

Jeder andere stößt darauf; Das hat bei mir auf Centos 6 Openldap und SSD funktioniert:

Anmerkungen: a. Einige "kluge Kerl" beschlossen, sssd TLS / SSL erfordern zu machen; Verhaltensänderung von Centos5; Das ist großartig für externe Systeme. aber wenn Sie über 300 Knoten in einer internen Appliance mit einem nicht erreichbaren internen Netzwerk für den Maschinencluster haben; Dies ist ein äußerst nutzloses Sicherheitsmerkmal.

b. Darüber hinaus scheinen selbst gesungene Zertifikate nicht mehr zu funktionieren; werde es weiter versuchen

c. Vermeiden Sie NSLCD um jeden Preis; wurde mit ununterbrochenen Ausgaben geplagt, als ich das Vermächtnisflag einstellte und anstelle von sssd verwendete (netgroups; Deadlocking Syslog, etc.).

Um mit sssd loszulegen;

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
   

Dies ist ein sehr häufiges Problem, keine Sorge, ich habe eine Antwort für Sie.

Erste RHEL Klone zwei haben haben ldap.confDateien, /etc/ldap.confoder in RHEL6 ist veraltet, aber Sie verwenden können , /etc/nslcd.conffür die Authentifizierung jetzt /etc/openldap/ldap.confist nur für Abfragen , so ldapsearch, ldapmodify, ldapremove, es ist wirklich Ihr Profil , so dass Sie haben müssen , um eine böse lange Zeichenfolge jedes Mal , wenn Sie nicht wollen , einen ldap-Befehl ausführen.

Damit stehen Ihnen zwei Parameter zur Verfügung:

• tls_cacertfile - Definieren Sie das Zertifikat explizit und Sie sollten einsatzbereit sein
• tls_cacertdir- in der ca cert in das Verzeichnis fallen , aber es wird nicht funktionieren, weil es muss gehasht werden ...

verwenden openssl x509 -hash -noout -in $file , ln -s $file $file.0, dann funktioniert Ihr CA-Zertifikat.

Auch beachten Sie, wenn die Konfigurationsdatei in CAPS ist, können Sie in /etc/openldap/ldap.conf arbeiten, sind sie sehr unterschiedliche Dateien.

Hoffe das klärt die Dinge auf.

Laut jeder Manpage, die ich gesehen habe (aber ich bin kein CentOS-Benutzer), gibt es keine LDAPTLS_CACERTDIR. Die richtige Variable ist TLS_CACERTDIR. Sie sollten es dauerhaft in /etc/openldap/ldap.confoder überall dort einstellen, wo CentOS die LDAP-Bibliothekskonfigurationsdatei aufbewahrt. Möglicherweise müssen Sie pam-ldap auch selbst konfigurieren, um nach CA-Zertifikaten zu suchen. In CentOS ist dies /etc/pam_ldap.conf, denke ich, und die zu setzende Variable ist tls_cacertdir.