Algunos sistemas no pueden conectarse a ldap a través de ldaps, pero otros sí, ¿es el certificado comodín?

Cuando intento hacer conexiones ldaps a mi servidor Novel eDirectory 8.8, a veces tengo que poner TLS_REQCERT neverel archivo ldap.conf de los servidores del cliente. Obviamente, esta es una mala idea.

El comando que ejecuto es algo así con credenciales que realmente funcionan ...

ldapsearch -x -H ldaps://ldapserver -b 'ou=active,ou=people,dc=example,dc=org' -D 'cn=admin,dc=example,dc=org' -W "cn=username"

En Ubuntu 13.10, funciona bien.

En SLES funciona bien.

En CentOS 6.5 devuelve:

ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)

Ahora, el certificado que he importado es un certificado comodín comprado en DigiCert. Mi compañero de trabajo encontró algunos informes que indican que algunos sistemas tienen problemas con los comodines.

Entonces, ¿el culpable es el comodín? Si es así, ¿cómo lo soluciono?

Si no es el certificado comodín, ¿qué es?

Siguiendo la sugerencia de Andrew Schulman, agregué -d1a mi comando ldapsearch. Esto es lo que terminé con:

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)

Por lo que dice, ¿CentOS no confía en DigiCert? ¿O CentOS no tiene una lista de emisores de confianza?

ssl-certificate ldap edirectory

— David R.
fuente

"No se puede contactar con el servidor LDAP" suena más como si el servidor no fuera accesible desde esa máquina cliente. ¿Ha verificado primero que de hecho puede conectarse a él? Por ejemplo telnet ldapserver ldapso openssl s_client -connect ldapserver:636.

— Richard E. Silverman

Sí, he confirmado que se puede conectar al servidor. Después de todo, nunca funcionaría si no pudiera conectarse.

— David R.

Usted mencionó tres hosts clientes diferentes. El que no funciona podría no haber podido conectarse debido a un problema de red, mientras que los otros sí.

— Richard E. Silverman

Pensé que mi publicación era bastante clara de que estaba editando el archivo ldap.conf en todos los hosts. Como cuando agregué la línea al archivo, funcionó, pero sin la línea no funcionó. Por lo tanto, no es un problema de conexión.

— David R.

Eso no estaba claro para mí cuando leí tu publicación inicialmente, aunque ahora entiendo lo que quieres decir. De todos modos, la información de depuración de TLS que ha agregado muestra el problema; He agregado una respuesta para dar seguimiento.

— Richard E. Silverman

Respuestas:

ldapsearch está buscando en / etc / openldap / cacerts su almacén de certificados de CA confiables, y aparentemente no está configurado, y por lo tanto está rechazando el certificado ya que no puede construir una cadena de confianza para él. Si ldapsearch estuviera usando OpenSSL, necesitaría una colección de formatos "hashdir" producida, por ejemplo, por el programa "authconfig" de Red Hat, o un solo archivo con una lista plana de certificados confiables. La referencia aquí a "moznss" sugiere que este ldapsearch está construido contra Mozilla NSS, en cuyo caso debe usar "certutil" para hacer el cert db (o mejor, apúntelo al almacén de certificados NSS del sistema, si hay uno) .

En los sistemas en los que funciona, ldapsearch debe tener un almacén de certificados en funcionamiento, tal vez porque esos paquetes de OpenLDAP están construidos en contra de OpenSSL (o tal vez haya un almacén de estilo NSS disponible allí).

— Richard E. Silverman
fuente

Ah /etc/openldap/certses donde está la tienda cert. No cacerts. En /etc/openldap/ldap.conf he cambiado TLS_CACERTDIR /etc/openldap/cacertsa TLS_CACERTDIR /etc/openldap/certsy mi comando ldapsearch comenzó a trabajar. ¡Gracias!

— David R.

Tengo instalado ldapsearch en Ubuntu 16.04, y no hay un directorio / etc / openldap.

— vcardillo

ldapsearch dirá "No se puede contactar con el servidor LDAP" si no puede verificar el certificado TLS. Agregue -d1a su comando ldapsearch y verifique las líneas de salida que comienzan con "TLS:" para obtener más información sobre si la conexión TLS falla y por qué.

— Andrew Schulman
fuente

Edité mi pregunta en respuesta a su sugerencia. ¡Gracias!

— David R.

La solución depende de su instalación:

Si está utilizando un certificado no válido , puede forzarlo a aceptar la configuración /etc/openldap/ldap.confcon
```
TLS_REQCERT allow
```
o
```
TLS_REQCERT never
```
Si está utilizando un certificado válido, probablemente su instalación ldap no sepa dónde está el almacén de certificados de CA confiables (probablemente dependiendo de su instalación de OpenSSL). Luego puede intentar establecer su ubicación y forzar la configuración de verificación /etc/openldap/ldap.confcon
```
TLS_CACERT /etc/openldap/cacert
TLS_REQCERT demand
```
/etc/openldap/cacertpuede ser esto o estar ubicado en cualquier camino. Debe contener la cadena de certificados de su CA. Puede ser un archivo único con una lista plana de certificados de confianza.

Las rutas de nota dependen del proveedor de ldap. Podría ser /etc/ldap, o /etc/openldapmás o menos.

— Juan garcia
fuente