No se puede usar SSL o TLS para acceder al servidor ldap de OpenDirectory

No puedo conectarme con mi sistema openserver mediante una conexión SSL/TLS.

No hay problemas para comunicarse sin SSL en el puerto 389 y puede conectarse y recuperar información del directorio sin problemas.

Sin embargo, al usar el puerto 636 y esperar comunicaciones seguras, la conexión falla.

El siguiente intento de conexión de openssl detalla el seguimiento que indicaría que no se está estableciendo ninguna conexión SSL.

Ejemplo de salida de openssl intentando conectarse

La siguiente imagen es de ServerAdmin que indica que SSL está habilitado y se ha proporcionado un certificado para la conexión del servidor.

Configuración de administrador del servidor

El puerto 636 está abierto en el servidor ldap y no hay firewall entre los dos hosts.

sauce:Java frank$ netstat -an | grep 636
tcp6       0      0  *.636                  *.*                    LISTEN
tcp4       0      0  *.636                  *.*                    LISTEN

Una conexión telnet al puerto 636 en el servidor tiene éxito, lo que indica que no hay problemas de firewall en juego.

¿Alguien puede proporcionar elementos adicionales para verificar para identificar y corregir la causa de este problema?

¿Cuál es el sistema operativo del servidor y cuál es el sistema operativo del cliente que está utilizando?
El sistema operativo del servidor es leopardo de nieve, el sistema operativo del cliente para fines de prueba es Linux
SSL handshake has read 0 bytes and written 319 bytes: esto parece que podría ser un problema de firewall. Verifique que el puerto esté abierto e intente deshabilitar el firewall. También puede verificar qué puertos están abiertos usando netstat -na.
Otro pensamiento: los bien conocidos puertos TCP y UDP de Apple enumeran el puerto TCP 625 como "Open Directory Proxy (ODProxy)", que " mantiene conexiones de proxy entrantes con el demonio opendirectoryd(8) local ", sea lo que sea que eso signifique. ¿Tal vez pruebe el puerto 625 en su lugar?

Respuestas (1)

Los siguientes fueron los pasos que tomé para resolver este problema:

Reinicie el servidor en modo seguro (mantenga presionada la tecla shift mientras reinicia)

Déjalo inactivo por un tiempo (aparentemente está limpiando cachés en este modo)

Detener el servidor slapd existente

 sudo launchctl unload /System/Library/LaunchDaemons/org.openldap.slapd.plist

Establezca el GUID de certificado correcto en el archivo /etc/openldap/slapd_macosxserver.conf . Esto se puede determinar a partir del contenido del directorio /etc/certificates

sudo sed -e 's/oldguid/newguid/' /etc/openldap/slapd_macosxserver.conf >/tmp/conffile
sudo mv /tmp/conffile /etc/openldap/slapd_macosxserver.conf

Elimine los valores del certificado TLS configurados del archivo /etc/openldap/slapd.d/cn=config.ldif

sudo vi /etc/openldap/slapd.d/cn=config.ldif
remove any lines beginning with olcTLSCertificate

Vuelva a iniciar el servidor slapd

 sudo launchctl load /System/Library/LaunchDaemons/org.openldap.slapd.plist

Reinicie el servidor nuevamente en modo estándar.

Luego, desde una computadora cliente con linux o mac osx, verifique que pueda conectarse a través de SSL y que los certificados sean correctos usando el comando

openssl s_client -connect ldap.yourdomain:636 -showcerts

Si tiene éxito, obtendrá un volcado de los certificados de su servidor, así como una descripción detallada de la conexión:

No client certificate CA names sent
---
SSL handshake has read 5209 bytes and written 807 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : AES256-SHA
    Session-ID: C8E0F4A4ED24021DB4D98ACF5A9ACDC2293BC3961BF2AE90026115D899369E73
    Session-ID-ctx: 
    Master-Key: 
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket:
    ...
    Start Time: 1400140597
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)

Algunas otras notas:

  1. Apple sugiere que puede usar cadenas de certificados propias y autofirmadas ( http://support.apple.com/kb/ht3745 ). Uso una cadena autofirmada y tiene éxito.
  2. El puerto 636 es el puerto ldaps estándar y es el puerto utilizado por OpenDirectory (slapd)
  3. TLS1 es compatible como se puede ver en la prueba de conexión de openssl
  4. Los diferentes nombres de DNS y nombres de host no importan (lo intenté en ambos sentidos con un reinicio en el medio)
  5. No importa el DNS inverso diferente (lo intenté en ambos sentidos con un reinicio en el medio)
No se puede usar SSL o TLS para acceder al servidor ldap de OpenDirectory
RespuestasAquíPolítica de privacidad1y, 0v