Un servidor Zimbra puede parecer en buen estado hasta que los usuarios reciben una advertencia en el navegador, como "certificado caducado", los clientes de correo rechazan la conexión SSL/TLS o un administrador descubre que el certificado ha caducado. La solución más rápida y segura no consiste en reemplazar todos los componentes del certificado de inmediato. Primero, determine qué componentes han caducado y, a continuación, renueve solo los necesarios.
El procedimiento actual del Centro Tecnológico de Zimbra para una implementación autofirmada de un solo servidor utiliza zmcertmgrla creación e implementación de certificados. Es importante destacar que Zimbra indica que la creación de una nueva Autoridad de Certificación (CA) es opcional para una renovación ordinaria de un certificado autofirmado; no es necesario reemplazar la CA cada vez que caduca el certificado del servidor. Las referencias oficiales utilizadas para esta guía se verificaron el 6 de octubre de 2026: Regenerar certificado SSL autofirmado: herramientas de certificados de la consola de administración y de la CLI para un solo servidor .
Zimbra utiliza certificados TLS en servicios como la interfaz web, el proxy, LDAP y los protocolos de correo electrónico. Una vez que un certificado caduca, los clientes pueden rechazar la conexión aunque los procesos subyacentes de Zimbra sigan en ejecución. Por lo tanto, una advertencia del navegador es solo un síntoma. Dependiendo de la topología y la política de clientes, también pueden aparecer fallos en las conexiones seguras IMAP/POP/SMTP, errores de proxy o problemas con LDAP/TLS.
Hay dos casos de vencimiento diferentes que conviene distinguir:
Antes de realizar cambios, cree una copia de seguridad o instantánea actualizada que se ajuste a su entorno. La regeneración de certificados suele ser sencilla, pero una copia de seguridad le proporciona un punto de recuperación si el servidor tiene personalizaciones antiguas, certificados instalados manualmente o una topología mixta.
Cambie a la cuenta de Zimbra e inspeccione el certificado actualmente implementado en los servicios locales:
su - zimbra
/opt/zimbra/bin/zmcertmgr viewdeployedcrtRevise las fechas de validez y el sujeto del certificado. Si el certificado aún está dentro de su período de validez, investigue la discrepancia en el nombre de host, una CA autofirmada no confiable, un certificado antiguo que todavía se sirve a través de un proxy o una hora incorrecta del servidor/cliente, en lugar de regenerar certificados innecesariamente.
También puede comprobar el certificado que un cliente remoto recibe realmente en HTTPS. Reemplace mail.example.comcon el nombre de host al que se conectan los usuarios:
openssl s_client -connect mail.example.com:443 -servername mail.example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -datesEsta comprobación remota resulta útil cuando viewdeployedcrttodo parece correcto, pero los navegadores siguen viendo un certificado antiguo, ya que prueba el certificado presentado a través de la red en lugar de solo los archivos en el disco.
Antes de cambiar los certificados, confirme el estado actual del servicio Zimbra para tener una referencia:
zmcontrol status
Si el certificado del servidor ha caducado y la CA de Zimbra sigue siendo válida, omita la recreación de la CA y vaya directamente a los comandos del certificado del servidor en la siguiente sección. Esto minimiza los cambios en la cadena de confianza. La documentación de Zimbra para servidores únicos indica explícitamente que la creación de una nueva CA es opcional y no es necesaria cada vez que se renueva un certificado autofirmado.
Si la CA ha caducado o tiene un motivo documentado para reemplazarla, cree una nueva:
/opt/zimbra/bin/zmcertmgr createca -new
/opt/zimbra/bin/zmcertmgr deployca
createca -newcomando sirve para reemplazar la CA de Zimbra cuando sea necesario, no es un paso obligatorio para cada renovación rutinaria de certificados hoja.
Para una renovación sencilla en un solo servidor, Zimbra documenta la siguiente secuencia. El ejemplo crea un certificado válido por 365 días:
/opt/zimbra/bin/zmcertmgr createcrt -new -days 365
/opt/zimbra/bin/zmcertmgr deploycrt selfSi los clientes se conectan a través de más de un nombre DNS, genere el certificado con los nombres alternativos del sujeto (Subject Alternative Names) requeridos en lugar de asumir que el nombre de host predeterminado es suficiente. La herramienta de certificados de Zimbra admite -subjectAltNames. Por ejemplo:
/opt/zimbra/bin/zmcertmgr createcrt -new -days 365 -subjectAltNames "mail.example.com,webmail.example.com"
/opt/zimbra/bin/zmcertmgr deploycrt selfUtilice nombres que correspondan realmente a este servicio de Zimbra y que sus usuarios o integraciones utilicen habitualmente. Un certificado puede estar vigente y aun así fallar la validación si el nombre de host solicitado no está incluido en sus valores de sujeto/SAN.
No utilice este procedimiento de autofirma para sobrescribir accidentalmente un certificado comercial o de confianza pública. Si su servidor debe usar un certificado comercial, deténgase aquí y siga el procedimiento de implementación de certificados comerciales de Zimbra.
Confirma que Zimbra haya implementado el nuevo certificado:
/opt/zimbra/bin/zmcertmgr viewdeployedcrtLuego, reinicie Zimbra para que los servicios carguen el nuevo certificado:
zmcontrol restartUna vez finalizado el reinicio, ejecute:
zmcontrol status
/opt/zimbra/bin/zmcertmgr viewdeployedcrtEl resultado deseado es sencillo: los servicios esperados están en funcionamiento y el certificado implementado ahora tiene una fecha de vencimiento futura. Finalmente, repita la prueba remota de OpenSSL con el nombre de host al que acceden los usuarios. Esto demuestra qué se está ofreciendo en la red después del reinicio.
No genere otro certificado de inmediato. Trabaje en las capas restantes en orden:
Para una instalación de varios nodos, utilice el procedimiento de múltiples servidores en lugar de repetir ciegamente los comandos de un solo servidor en cada host. Zimbra documenta la creación/implementación de la CA y luego la implementación del certificado autofirmado en todos los nodos con deploycrt self -allserver; también advierte que viewdeployedcrtsolo informa del servidor local. La referencia oficial es Regenerar certificado SSL autofirmado — Multi-Server .
Una discrepancia en la CA entre un servidor LDAP maestro y sus réplicas puede generar problemas de TLS y replicación. Si utiliza una topología de varios servidores, verifique la cadena de CA en cada nodo afectado y siga el orden de implementación documentado.
Antes de cerrar el incidente, verifique lo siguiente:
zmcontrol statusmuestra que los servicios de Zimbra esperados están en funcionamiento.zmcertmgr viewdeployedcrtMuestra un certificado cuya fecha de vencimiento es futura.openssl s_clientcomprobación remota devuelve las mismas fechas de certificado nuevo para el nombre de host público/interno que los usuarios utilizan realmente.Para la caducidad rutinaria de un único servidor, la solución menos disruptiva suele ser mantener una CA de Zimbra aún válida, crear un nuevo certificado de servidor autofirmado, implementarlo, reiniciar los servicios y verificar el certificado desde fuera del servidor. Reemplace la CA solo cuando haya caducado o exista otra razón clara para rotarla. Este enfoque soluciona la interrupción inmediata y evita cambios innecesarios en la cadena de confianza.
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.
