El daemon Slapd no puede iniciarse: TLS init def ctx falló: -1

Recomiendo crear otro certificado autofirmado en Server.app que pueda usar para asegurar los servicios (si los otros fueron vencidos / eliminados). Al crear el certificado utilizando Server.app, estará automáticamente disponible para otros servicios (como Open Directory).

Una vez que haya creado un nuevo certificado autofirmado, siga los pasos 6 a 12 de este artículo (que describen cómo puede configurarse su certificado SSL para su uso con Open Directory). Ejecutando el Open Directory - > Configuración - > LDAP - > La configuración SSL a través de Server Admin escribirá las rutas de certificado correctas en el archivo de configuración slapd .

Una vez que haya corregido los problemas del certificado, Open Directory ( slapd ) debería iniciarse normalmente (sin que tenga que iniciarlo manualmente). Si Password Server sigue sin mostrarse ejecutándose después de eso, puede intentar reiniciar (o verificar si está generando registros de fallos u otros errores en la Consola).

Editar

Después de modificar la configuración del certificado para su uso con LDAP, es probable que valga la pena verificar que la máquina haya proporcionado rutas de certificado actualizadas a slapd en el archivo slapd_macosxserver.conf . Es decir, la cadena única de números y caracteres en las rutas clave / cert debería haber cambiado.

Para confirmar que slapd puede acceder a la clave privada correspondiente para el certificado con el que está asegurando los servicios LDAP, puede verificar el archivo en /etc/openldap/slapd_macosxserver.conf ... Busque una línea que mencione certadmin ... Esa línea especifica el comando que slapd está utilizando para recuperar la clave privada del llavero. Es posible ejecutar ese comando (copiar y pegar) en la Terminal para ver si se puede recuperar la frase de contraseña de la clave privada:

/usr/sbin/certadmin --get-private-key-passphrase /etc/certificates/domain.com.456DACFFC771F8EB2F5A8E0EBB269969B8164097.key.pem

Una vez que haya recuperado la frase de contraseña, vea si puede ver la clave privada usando esa frase de contraseña:

sudo openssl rsa -in /etc/certificates/domain.com.456DACFFC771F8EB2F5A8E0EBB269969B8164097.key.pem -text -noout

Cuando se le solicite la frase de paso, copie y pegue el valor que obtuvo en el paso anterior. Debería ver la salida de datos de clave privada en la pantalla. Esto confirmaría que:

1.) Su frase de contraseña privada se puede recuperar del llavero

2.) La frase de contraseña en el llavero se puede usar para descifrar la clave

Si no puede obtener la contraseña y desbloquear la clave, es posible que slapd tampoco pueda hacerlo. Creo que el software está utilizando un elemento de llavero en el llavero del sistema llamado "Administración de certificados del servidor Mac OS X" con un tipo de "contraseña de aplicación". La "Cuenta" para ese elemento de llavero debe configurarse con la misma cadena única de caracteres y números ( 456DACFFC771F8EB2F5A8E0EBB269969B8164097 en este ejemplo) que ve en las rutas cert / key en /etc/certificates . Si no ve una de estas contraseñas de aplicación correspondientes en el llavero del sistema, puede ser su problema.

Lo siguiente se probó en las versiones snow-leopard 10.6 y lion 10.7 del sistema operativo cuando el servidor LDAP de OpenDirectory no se inicia y el servidor de contraseñas aún se está ejecutando.

Si observa la cola del archivo sudo tail /etc/openldap/slapd.d/cn=config.ldif , verá un conjunto de entradas de certificados TLS similares al bloque a continuación:

olcTLSCertificateFile: /etc/certificates/[myservername].ECA88C7518AEDE947AAC94D9A259D1B2E5621169.cert.pem

olcTLSCACertificateFile: /etc/certificates/[myservername].ECA88C7518AEDE947AAC94D9A259D1B2E5621169.chain.pem

olcTLSCertificateKeyFile: /etc/certificates/[myservername].ECA88C7518AEDE947AAC94D9A259D1B2E5621169.key.pem

olcTLSCertificatePassphraseTool: /usr/sbin/certadmin --get-private-key-passphrase /etc/certificates/[myservername].ECA88C7518AEDE947AAC94D9A259D1B2E5621169.key.pem

entryCSN: 20120628190714.643255Z#000000#001#000000

Si compara estas entradas con los valores que se muestran en / etc / certificados, es muy probable que encuentre que el número mágico es diferente para su certificado con el valor que se muestra en el directorio / etc / certificate para sus certificados.

Si ejecuta el comando

sudo /usr/libexec/slapd -d 1

verá hacia el final de la traza una línea que se aproxima

TLS: could not load verify locations (file:'/etc/certificates…

Para superar este problema, elimine las últimas cinco líneas del archivo /etc/openldap/slapd.d/cn=config.ldif manualmente usando su editor favorito y sudo .

Luego, para reiniciar ldap emita los siguientes comandos

sudo /usr/bin/db_recover -h /var/db/openldap/openldap-data
sudo launchctl load /System/Library/LaunchDaemons/org.openldap.slapd.plist

Todo debería ser arreglado.