El mensaje Unable to start TLS: SSL handshake failedindica que el cliente y el servidor no pudieron completar la negociación que inicia una conexión cifrada. En Zimbra, este mensaje puede provenir de diferentes fuentes. Una variante frecuente indica que zmcontrol statusla conexión con el servidor maestro LDAP falló la verificación del certificado. Un cliente de correo o un servidor de retransmisión SMTP también pueden reportar un problema de establecimiento de conexión en un puerto de correo público.
La solución depende de qué conexión falló. Comience por identificar el servicio y el nombre de host en las líneas de registro circundantes. Luego, verifique el certificado, su cadena de emisión, el reloj del sistema y el punto final TLS. Evite deshabilitar TLS como primera medida: esto puede ocultar el problema y, al mismo tiempo, debilitar o interrumpir la comunicación interna del servidor de correo.
TLS es el protocolo que cifra una conexión de red. El intercambio inicial de claves TLS consiste en que ambos sistemas acuerdan los parámetros de cifrado y validan el certificado del servidor. STARTTLS comienza como una conexión de protocolo simple y luego cambia a TLS cuando ambas partes lo solicitan. Tanto LDAP como SMTP pueden usar STARTTLS, por lo que este error por sí solo no identifica el servicio que está fallando.
Antes de ejecutar comandos de reparación, registre la versión de Zimbra, si la instalación es de un solo nodo o de varios nodos, el comando o cliente exacto que muestra el error y la línea completa del registro que lo rodea. Programe la implementación de certificados o el reinicio del servicio durante una ventana de mantenimiento. Conserve una copia de seguridad de los archivos de certificado y la configuración antes de editarlos.
Primero, reproduzca el problema y lea el mensaje completo. Si aparece cuando Zimbra comprueba el estado del servicio e incluye un texto como este when connecting to ldap master, investigue el TLS LDAP interno. Si solo falla un cliente de correo al enviar el mensaje SMTP, investigue el punto final SMTP público y el nombre de host, el puerto y el modo de cifrado del cliente.
su - zimbra
zmcontrol status
Revise las entradas recientes del registro de Zimbra con la misma marca de tiempo. En muchas instalaciones, el registro principal es /var/log/zimbra.log; utilice la ubicación del registro configurada en su servidor.
grep -Ei 'Unable to start TLS|SSL handshake|certificate|ldap|STARTTLS' /var/log/zimbra.log | tail -n 80
Busque el nombre del proceso, el host remoto, el puerto y cualquier otro detalle específico de OpenSSL, como un error de verificación del certificado, un certificado caducado, un emisor desconocido o una alerta de protocolo. Estos detalles permiten distinguir un problema de confianza en el certificado de una discrepancia de red o de protocolo.
Para un error interno de LDAP, compruebe qué hosts LDAP está configurado para usar este servidor. Consulte las claves de configuración local individualmente y compare sus nombres de host con el DNS y el certificado del servidor:
zmlocalconfig ldap_url
zmlocalconfig ldap_master_url
zmlocalconfig ldap_starttls_supported
zmlocalconfig ldap_starttls_required
La disponibilidad y el resultado de las claves pueden variar según la versión de Zimbra y la función del nodo. Estas son lecturas de diagnóstico; no cambie un valor solo porque aparezca en el resultado. La documentación de Zimbra describe la función de la configuración LDAP STARTTLS y recomienda mantener TLS interno habilitado: Valores de configuración local de Zimbra TLS y STARTTLS .
La validación del certificado depende de la hora del servidor. Si el reloj está muy atrasado o adelantado, un certificado válido puede aparecer como no válido o caducado. Confirme la hora en el host de Zimbra y en cualquier servidor LDAP (maestro o réplica) involucrado en la conexión.
date -u
getent hosts ldap.example.com
Sustituya ldap.example.comel nombre de host LDAP por el que se encuentra en la configuración o el registro. Confirme que se resuelve a la dirección del servidor esperada y que el puerto LDAP configurado es accesible a través del firewall y la red del host. En instalaciones multinodo, realice la prueba desde el nodo Zimbra que registró el fallo hasta el nodo LDAP real, no solo desde su estación de trabajo.
Para una conexión SMTP STARTTLS orientada al cliente, la guía de solución de problemas SMTP de Zimbra muestra cómo probar el puerto 25 con OpenSSL. El puerto 587 también se usa comúnmente para el envío de mensajes con STARTTLS. Utilice el nombre de host y el puerto configurados en el cliente de correo:
openssl s_client -starttls smtp -connect mail.example.com:587 -servername mail.example.com -showcerts
Para SMTP en el puerto 25, reemplace 587con 25. El puerto 465 usa TLS implícito, así que no agregue -starttls smtpal probar ese puerto. Una conexión TCP exitosa no prueba por sí sola que el certificado sea confiable o que el cliente esté usando el modo de seguridad correcto. Consulte la guía de solución de problemas de SMTP y OpenSSL de Zimbra .
Un certificado es un documento de identidad firmado para un servidor. El certificado debe ser válido para el nombre de host que utilizan los clientes, estar dentro de su período de validez y estar vinculado a una autoridad de certificación en la que confíe el componente de conexión. Un certificado puede parecer correcto en un navegador, aunque se haya implementado un certificado diferente en LDAP, Postfix o un nodo proxy.
Como administrador de Zimbra, vea el certificado que Zimbra informa como implementado:
/opt/zimbra/bin/zmcertmgr viewdeployedcrt
Verifique el sujeto o el nombre alternativo del sujeto (SAN), el emisor, la fecha de vencimiento y los servicios de cada certificado listado. El SAN debe contener el nombre de host utilizado para la conexión LDAP o de correo electrónico. Compruebe también que todos los nodos en una implementación de varios servidores tengan el certificado y la cadena esperados. Zimbra indica que la visualización de los certificados implementados es local al servidor, por lo que debe ejecutar la verificación en cada nodo pertinente.
Si dispone de los archivos de certificado de origen, revise sus fechas y nombres antes de la implementación:
openssl x509 -in /tmp/commercial.crt -noout -dates -subject -issuer -ext subjectAltName
Sustituya la ruta de ejemplo por el archivo de certificado que está evaluando. La ausencia de SAN, un certificado intermedio o de hoja caducado, un nombre de host incorrecto o un certificado emitido para otro servidor pueden provocar un fallo en la validación.
La cadena de certificados es el conjunto de certificados emisores que permite a un cliente rastrear el certificado del servidor hasta una autoridad de confianza. Si el archivo de la cadena omite un certificado intermedio o contiene una cadena incorrecta, los clientes pueden rechazar el servidor incluso cuando el certificado final está vigente. El certificado y la clave privada también deben coincidir.
Para un certificado comercial, las herramientas de certificados de Zimbra proporcionan un paso de verificación. Adapte las rutas de archivo a su instalación y autoridad de certificación:
/opt/zimbra/bin/zmcertmgr verifycrt comm /opt/zimbra/ssl/zimbra/commercial/commercial.key /tmp/commercial.crt /tmp/ca_chain.crt
Proceda únicamente si la verificación confirma que el certificado y la clave privada coinciden y que la cadena de certificados es válida. No implemente un certificado tras una verificación fallida. Utilice la cadena intermedia proporcionada por la autoridad de certificación y el formato de cadena compatible con su versión de Zimbra; no cree una cadena adivinando o añadiendo certificados raíz no relacionados.
La guía de certificados de Zimbra documenta la secuencia de verificación e implementación, incluida la cadena de CA: Instalación de certificados de Zimbra y herramientas de CLI . Su página de solución de problemas de la cadena de certificados también explica los errores de verificación de la cadena del emisor: Guía de la cadena de certificados de Zimbra .
Si la verificación muestra un certificado caducado, una clave incorrecta, un certificado intermedio faltante o una discrepancia en el nombre de host, obtenga o genere los archivos correctos antes de la implementación. Siga el procedimiento correspondiente a su versión de Zimbra y tipo de certificado. Para un certificado comercial, el comando documentado tiene esta forma general:
/opt/zimbra/bin/zmcertmgr deploycrt comm /tmp/commercial.crt /tmp/ca_chain.crt
Utilice la sintaxis de comandos y los privilegios exactos documentados para la versión instalada. La CLI de Zimbra puede instalar certificados para componentes como el MTA, LDAP y el proxy, por lo que la implementación puede afectar a varios servicios. En un entorno de varios nodos, confirme que el certificado se haya implementado correctamente en todos los servidores pertinentes, incluido el servidor maestro LDAP.
Tras verificar el despliegue, reinicie los servicios de Zimbra durante la ventana de mantenimiento planificada si el procedimiento de lanzamiento lo requiere; a continuación, confirme el estado del servicio y los certificados desplegados:
su - zimbra
zmcontrol restart
zmcontrol status
/opt/zimbra/bin/zmcertmgr viewdeployedcrt
Un reinicio interrumpe el acceso al correo y a la web mientras los servicios se detienen y se restablecen. No lo ejecute de forma casual en un servidor de producción con mucha actividad. La guía de certificados de Zimbra documenta el uso zmcontrol restartdespués de la implementación y la comprobación del resultado con viewdeployedcrt.
Si el certificado se verifica correctamente, pero el cliente LDAP de Zimbra lo rechaza, inspeccione el material de confianza LDAP y el nodo que presenta el problema. La nota de solución de problemas de MTA archivada de Zimbra enumera una cadena de CA no válida, certificados de CA caducados y archivos inesperados entre /opt/zimbra/conf/calas posibles causas de fallos de LDAP STARTTLS. Considere esto como una pista de diagnóstico, no como un motivo para eliminar archivos: compare el directorio con una copia de seguridad válida o con la guía específica de la versión y conserve su contenido antes de realizar cambios.
Para una simple consulta LDAP STARTTLS, un cliente OpenLDAP puede requerir StartTLS y consultar el DSE raíz sin proporcionar credenciales de cuenta:
ldapsearch -x -ZZ -H ldap://ldap.example.com:389 -b "" -s base namingContexts
Utilice el host y el puerto LDAP reales de su implementación. Con las herramientas de OpenLDAP, -ZZse solicita StartTLS y se considera un error si no se logra establecer la conexión. Si esta prueba falla con un mensaje de confianza o certificado, compare el certificado devuelto por el punto final LDAP con el certificado implementado y la confianza de CA disponible para el cliente. Si la prueba se realiza correctamente en un nodo pero falla en otro, investigue las diferencias en DNS, archivos CA o la configuración local.
El establecimiento de la conexión también puede fallar si el cliente y el servidor no coinciden en la versión del protocolo TLS o el conjunto de cifrado. Esto puede ocurrir con clientes obsoletos, medidas de seguridad personalizadas o configuraciones predeterminadas específicas de la versión. Pruebe el punto final con un cliente OpenSSL actualizado e inspeccione la configuración TLS de Zimbra para verificar la versión exacta del producto. Evite copiar comandos de protocolo antiguos de páginas archivadas en una instalación más reciente; la configuración del cifrado y del protocolo puede cambiar entre versiones.
No intente solucionar el error habilitando SSLv3, debilitando la verificación ni deshabilitando globalmente LDAP STARTTLS. En un hilo del foro de Zimbra se menciona una solución alternativa que desactivaba LDAP STARTTLS, pero otro usuario advirtió correctamente que deshabilitar una función de seguridad no es una solución eficaz para reparar el certificado. Las propias notas de configuración local de Zimbra recomiendan mantener habilitados TLS entre procesos y LDAP STARTTLS. Utilice este cambio únicamente como un diagnóstico temporal y estrictamente controlado si el soporte de Zimbra se lo indica, y restaure la configuración segura de inmediato.
zmcontrol statusSe completa sin el error LDAP TLS, si esa era la operación que fallaba.Si el problema persiste, recopile el error completo, la versión de Zimbra, el servicio y el nombre de host afectados, las fechas del certificado y el SAN, la salida de verificación y las líneas de registro relevantes. Oculte las claves privadas, las credenciales, las direcciones de usuario y los detalles confidenciales del host antes de compartirlos. El mensaje exacto es un síntoma, no un diagnóstico completo; el nombre del servicio y el motivo de OpenSSL determinan la solución adecuada.
Nota de documentación: Las páginas públicas de certificados y TLS de Zimbra incluyen información de varias versiones, y algunas páginas de solución de problemas están archivadas explícitamente. Los comandos aquí descritos siguen el patrón de la interfaz de línea de comandos (CLI) documentado, pero las rutas de los certificados, los privilegios y los requisitos de reinicio deben consultarse en la documentación de la versión de Zimbra instalada. Revisado el 6 de octubre de 2026.
Compara 10 herramientas de escaneo de ping para la detección rápida de redes LAN, el escaneo multiplataforma y la gestión de direcciones IP. Descubre qué puede (y qué no puede) revelarte un escaneo.
Compare seis herramientas de gestión de red para la monitorización del rendimiento, incluyendo la cobertura SNMP, la asignación de mapas, las alertas, los modelos de implementación y las ventajas y desventajas en cuanto a costes.
Compara las mejores aplicaciones de análisis Wi-Fi para Windows, iPhone y Android, incluyendo herramientas para la congestión de canales, la cobertura de la señal, los mapas de calor y la resolución de problemas de red.
Compara siete monitores de ping gratuitos y de código abierto, desde suites de red completas hasta sondas de latencia específicas, y elige el que mejor se adapte a tus necesidades en cuanto a disponibilidad, pérdida de paquetes e historial.
Aprenda qué significa QoS en redes, cómo las marcas DSCP y las colas de tráfico priorizan las aplicaciones de voz, vídeo y empresariales, y qué problemas no puede solucionar la QoS.
Compare siete herramientas de administración de direcciones IP para el descubrimiento de subredes, la coordinación de DNS y DHCP, el inventario de red y la gestión de direcciones IP de código abierto.
Compara software de servidor SFTP fiable para Windows y Linux, incluyendo OpenSSH, Bitvise, SolarWinds y SFTPGo. Encuentra la solución ideal para tus necesidades de seguridad y transferencia de archivos.
Cree un sistema práctico de monitorización de red con una cobertura clara de los dispositivos, métricas de rendimiento útiles, alertas procesables y una comparación de SolarWinds NPM, PRTG y OpManager.
Compare las herramientas de escaneo de red para la detección rápida de dispositivos, escaneos de IP multiplataforma y gestión de direcciones IP (IPAM) empresariales, con orientación sobre cómo adaptar cada opción a su red.
Utilice la opción --traceroute de Nmap para asignar saltos a un host autorizado, comprender la salida de saltos y RTT, y solucionar problemas de respuestas faltantes sin realizar un escaneo excesivo.
