Problemas de confianza del certificado de CentOS openLDAP

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

opensslparece pensar que el certificado está bien, pero openldaplas bibliotecas ( pam_ldapexhiben un comportamiento similar, que es cómo llegué a este lío) no están de acuerdo.
¿Qué estoy haciendo mal?

De hecho, RHEL no proporciona nada que pueda usarse como un "directorio de certificados" para fines de confianza de CA. Para OpenSSL, un directorio de certificados, un 'CApath', es un directorio que contiene archivos de certificados individuales (en formato PEM o el formato de 'certificado de confianza' extendido de OpenSSL), con nombres en un formato específico basado en un hash del nombre del sujeto del certificado. Por lo general, esto se logra colocando archivos con nombres y .pemextensiones legibles por humanos en un directorio y ejecutándolo c_rehash(verman c_rehash) Para GnuTLS desde 3.3.6 (antes de eso, GnuTLS no tenía soporte de directorio), es solo un directorio con archivos PEM; GnuTLS intentará cargar cada archivo en el directorio y tendrá éxito en cualquier cosa PEM-ish (no puede manejar el formato de 'certificado de confianza' de OpenSSL). Honestamente, no estoy seguro de si NSS realmente puede usar un directorio lleno de archivos de certificados individuales como una raíz de confianza de alguna manera, pero la documentación de OpenLDAP parece sugerir que sí puede (pero si el directorio también contiene una base de datos NSS le dará esa prioridad). En cualquier caso, RHEL no tiene nada como un directorio lleno de archivos de certificados de CA individuales.

Debian y derivados proporcionan /etc/ssl/certsen este formato; /etc/ssl/certses la ubicación de la tienda de confianza canónica en Debian, y la OMI, todo lo que la proporcione debería básicamente presentarla como Debian, ya que Debian tenía ese directorio presentado más o menos de la misma manera desde 1999. RHEL tiene un /etc/ssl/certsdirectorio, pero está en no en este formato: no contiene ningún archivo de certificado individual. No puedes usarlo como un CApath. Honestamente, en RHEL (y Fedora, y derivados) ese directorio es básicamente una trampa. No lo uses (Ver https://bugzilla.redhat.com/show_bug.cgi?id=572725 y https://bugzilla.redhat.com/show_bug.cgi?id=1053882para algunos antecedentes sobre por qué existe en primer lugar y cómo estoy tratando de arreglarlo). Así que creo que tienes razón sobre lo que está sucediendo, pero equivocado sobre la razón por la cual. OpenLDAP no está haciendo nada mal, y no está fallando porque "ca-bundle.trust.crt ... es una base de datos cert / key de Mozilla NSS" (se llaman cert8/9.dby key3/4.db, y los de todo el sistema en RHEL viven /etc/pki/nssdb) , simplemente está fallando porque /etc/ssl/certsno se puede usar como un "directorio de certificados" en absoluto.

RHEL tampoco proporciona nada utilizable como una tienda de confianza de estilo CApath en ningún otro lugar. El almacén de confianza del sistema de RHEL se proporciona como un único archivo de paquete PEM (un 'CAfile' en términos de OpenSSL), que se puede encontrar en /etc/pki/tls/certs/ca-bundle.crty /etc/pki/tls/cert.pem. También se puede encontrar en, /etc/ssl/certs/ca-bundle.crtya /etc/ssl/certsque en realidad es solo un enlace simbólico /etc/pki/tls/certs, pero esa ubicación no es canónica y realmente nunca debería ser utilizada por nada. RHEL también proporciona un paquete en formato de 'certificado de confianza' de OpenSSL como /etc/pki/tls/certs/ca-bundle.trust.crt.

Lo que debe hacer, como descubrió, es utilizar el archivo de paquete que proporciona el sistema. Su respuesta funcionará, pero por las razones mencionadas anteriormente, lo recomendaría encarecidamente TLS_CACERT=/etc/pki/tls/certs/ca-bundle.crto TLS_CACERT=/etc/pki/tls/cert.pemmás TLS_CACERT=/etc/ssl/certs/ca-bundle.crt.

(No hay nada remotamente nuevo en nada de esto, por cierto, pero la confusión en las interwebs es generalizada. RH y derivados nunca han proporcionado un directorio lleno de certificados, nunca. Han proporcionado un archivo de paquete desde el año 2000. Fue se mudó de / usr / share / ssl a / etc / pki / tls en 2005. Debian ha tenido tanto /etc/ssl/certsun directorio de estilo CApath /etc/ssl/certs/ca-certificates.crtcomo un archivo de paquete más o menos desde la edad de piedra).

/etc/ssl/certs/contiene /etc/ssl/certs/ca-bundle.trust.crtcomo parte de ca-certificates-2010.63-3.el6_1.5.noarch, que es una base de datos cert / key de Mozilla NSS. La inclusión de este archivo TLS_CACERTDIRhace que todos los demás archivos sean ignorados.

TLS_CACERTDIR
Especifica la ruta de un directorio que contiene certificados de Autoridad de certificación en archivos individuales separados. TLS_CACERT siempre se usa antes de TLS_CACERTDIR.` Este parámetro se ignora con GnuTLS.

Cuando se utiliza Mozilla NSS, puede contener una base de datos cert / key de Mozilla NSS. Si contiene una base de datos cert / key de Mozilla NSS y archivos cert de CA, OpenLDAP utilizará la base de datos cert / key e ignorará los archivos cert de CA. ''

Sin embargo, openldap-2.4.23-26.el6_3.2.i686no parece manejar esto correctamente.

Uso de respuesta cortaLDAPTLS_CACERT=/etc/ssl/certs/ca-bundle.crt
(archivo de configuración TLS_CACERT=/etc/ssl/certs/ca-bundle.crt)
Este archivo también se incluye proporcionado por ca-certificates-2010.63-3.el6_1.5.noarch.

Alguien más se encuentra con esto; esto es lo que funcionó para mí en centos 6 openldap y sssd:

notas: a. Algún "chico inteligente" decidió hacer que sssd requiriera TLS / SSL; cambio de comportamiento de centos5; esto es genial para sistemas externos; pero cuando tiene más de 300 nodos en un dispositivo interno con una red interna inalcanzable para el clúster de la máquina; Esta es una característica de seguridad extremadamente inútil.

si. Además, los certificados autoquenados ya no parecen funcionar; continuará intentando

C. Evite NSLCD a toda costa; estaba plagado de problemas ininterrumpidos cuando configuré el indicador heredado y lo usé en lugar de sssd (netgroups; syslog de bloqueo, etc.).

Para comenzar a usar 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
   

Este es un problema muy común, no se preocupe, tengo una respuesta para usted.

Primeros RHEL clones tienen dos ldap.confarchivos, /etc/ldap.confo en RHEL6 se está en desuso pero se puede utilizar /etc/nslcd.confpara la autenticación ahora /etc/openldap/ldap.confes sólo para consultas , por lo que ldapsearch, ldapmodify, ldapremove, es realmente su perfil por lo que no tiene que tener una cadena larga desagradable cada vez que desee ejecutar un comando ldap.

Ahora con eso fuera del camino, tienes dos parámetros,

• tls_cacertfile - defina explícitamente el certificado de certificación y debería estar listo para comenzar
• tls_cacertdir- coloque el certificado de ca en el directorio pero no funcionará, porque necesita ser hash ...

use openssl x509 -hash -noout -in $file , ln -s $file $file.0, entonces su certificado de CA funcionará.

También tenga en cuenta que si el archivo de configuración está en CAPS, está trabajando en /etc/openldap/ldap.conf, son archivos muy diferentes.

Espero que esto aclare las cosas.

De acuerdo con la página de cada hombre que he visto (pero no soy un usuario de CentOS) no existe tal cosa LDAPTLS_CACERTDIR. La variable correcta para establecer es TLS_CACERTDIR. Debe configurarlo permanentemente en /etc/openldap/ldap.confo donde CentOS guarde el archivo de configuración de la biblioteca LDAP. Además, es posible que deba configurar pam-ldap para buscar los certificados de CA. En CentOS esto es /etc/pam_ldap.conf, creo, y la variable a establecer es tls_cacertdir.