Cómo instalar un certificado SSL comercial en un servidor Zimbra

Un certificado SSL comercial en Zimbra puede presentar varios problemas frustrantes, incluso cuando la autoridad certificadora indica que se emitió correctamente. Los problemas más comunes no suelen estar relacionados con el certificado en sí: la clave privada no coincide con el certificado devuelto, falta una CA intermedia, el nombre de host no aparece en el Nombre Alternativo del Sujeto (SAN) del certificado, o el administrador implementa los archivos antes de validar la cadena.

La forma más segura de realizar esta tarea es tratarla como una secuencia de comprobaciones en lugar de un único comando para "instalar el certificado". La herramienta de certificados documentada de Zimbra zmcertmgrpuede crear una solicitud de firma de certificado (CSR), verificar la clave privada y la cadena de CA, implementar el certificado en los servicios de Zimbra y mostrar el certificado que está activo actualmente. El Centro Técnico oficial de Zimbra documenta estos comandos en su guía de herramientas de certificados para la consola de administración y la CLI .

Así debería ser una instalación exitosa de Zimbra SSL.

Antes de realizar cualquier cambio, defina el resultado que desea. Una implementación correcta debe cumplir todas estas condiciones:

• La lista SAN del certificado incluye todos los nombres de host públicos que los clientes utilizan realmente, como por ejemplo mail.example.com.
• El certificado emitido coincide con la clave privada almacenada para el certificado comercial.
• Zimbra puede validar la cadena completa, desde el certificado del servidor, pasando por los certificados de CA intermedios, hasta la CA raíz.
• zmcertmgr deploycrt commSe completa sin errores de coincidencia de claves ni de validación de cadena.
• Los servicios de Zimbra se reinician correctamente.
• zmcertmgr viewdeployedcrtmuestra el certificado esperado.
• Un navegador o un cliente TLS que se conecta al nombre de host público ve el nuevo certificado y ninguna advertencia de confianza.

Si alguna de estas comprobaciones falla, corrija esa capa específica antes de continuar. Volver a implementar repetidamente los mismos archivos rara vez resuelve un problema de clave, SAN o cadena.

Antes de comenzar: elija el flujo de trabajo de certificados adecuado.

La página actual del Centro Tecnológico de Zimbra indica que en Zimbra 8.7 y versiones posteriores, zmcertmgrse ejecuta como el zimbrausuario. También documenta que la clave privada comercial debe tener el nombre especificado commercial.keyen /opt/zimbra/ssl/zimbra/commercialy que el certificado del servidor más el archivo de la cadena de CA deben almacenarse en un directorio temporal antes de la implementación.

Paso 1: haga una copia de seguridad del material del certificado actual.

No comience eliminando el directorio SSL existente. Primero cree una copia de seguridad que pueda restaurar si la nueva implementación falla. Como usuario root, un ejemplo conservador es:

cp -a /opt/zimbra/ssl/zimbra /opt/zimbra/ssl/zimbra.backup-$(date +%Y%m%d-%H%M%S)

Además, registre el certificado actualmente implementado antes de cambiarlo:

su - zimbra
/opt/zimbra/bin/zmcertmgr viewdeployedcrt

Esto proporciona una base de comparación tras el cambio. Si su entorno cuenta con varios nodos Zimbra, capture el estado actual del certificado en cada servidor pertinente en lugar de asumir que son idénticos.

Paso 2: genere una CSR con los nombres de host que realmente necesita.

Para un nuevo certificado comercial, cree la CSR con el nombre de host de producción y cualquier SAN adicional. Zimbra documenta la siguiente sintaxis:

/opt/zimbra/bin/zmcertmgr createcsr comm -new \
-subject "/C=US/ST=CA/L=Sunnyvale/O=Example/OU=IT/CN=mail.example.com" \
-subjectAltNames "mail.example.com"

Si los usuarios también se conectan mediante otro nombre, como webmail.example.com, inclúyalo en la lista SAN al solicitar el certificado. Los clientes TLS modernos validan los nombres de host con respecto a los SAN, por lo que un certificado que parezca correcto solo por el nombre común aún puede generar una advertencia del navegador si falta el nombre de host.

Revise la solicitud de firma de certificado (CSR) antes de enviarla a su autoridad de certificación:

/opt/zimbra/bin/zmcertmgr viewcsr comm /opt/zimbra/ssl/zimbra/commercial/commercial.csr

Punto de control: deténgase aquí si los nombres DNS solicitados son incorrectos. Si primero se emite el certificado y luego se descubre que falta un SAN, normalmente deberá volver a emitirlo la CA.

Paso 3: recopilar el certificado del servidor y la cadena completa de la CA.

Tras la validación, su CA comercial normalmente devuelve el certificado del servidor más uno o más certificados intermedios. El procedimiento oficial de Zimbra para certificados comerciales de nodo único espera el certificado del servidor en formato PEM e indica a los administradores que combinen los certificados CA intermedios y raíz en un archivo de cadena.

Un diseño de escenario típico es:

/tmp/commercial.crt
/tmp/ca_intermediary.crt
/tmp/ca.crt

Luego, construya la cadena en el orden documentado por Zimbra:

cat /tmp/ca_intermediary.crt /tmp/ca.crt > /tmp/ca_chain.crt

Utilice los archivos proporcionados por su autoridad de certificación para su producto de certificado exacto. No copie un certificado intermedio de un tutorial no relacionado simplemente porque el nombre de la marca de la CA parezca similar. Las jerarquías de las CA cambian con el tiempo, y un certificado intermedio incorrecto es una causa común de problemas unable to get local issuer certificate.

Paso 4: verifique la clave privada, el certificado del servidor y la cadena antes de la implementación.

Esta es la medida de seguridad más importante. Ejecute el comando de verificación documentado como usuario de Zimbra en las versiones actuales de Zimbra:

su - zimbra
/opt/zimbra/bin/zmcertmgr verifycrt comm \
/opt/zimbra/ssl/zimbra/commercial/commercial.key \
/tmp/commercial.crt \
/tmp/ca_chain.crt

Un informe de verificación exitoso indica que el certificado y la clave privada coinciden y que el certificado es válido. La documentación de las herramientas de certificados de Zimbra explica que esto verifycrtcombina una verificación de clave y una verificación de la cadena de certificados.

Si la verificación falla, elija la solución en función del error.

• Certificado y clave privada no coincidentes: el certificado de la CA no se emitió a partir de la CSR asociada al certificado actual commercial.key. Restaure la clave correcta o vuelva a emitir el certificado a partir de una nueva CSR.
• No se puede validar la cadena de certificados: el paquete intermedio/raíz está incompleto, en el orden incorrecto, ha caducado o no corresponde a la cadena de este certificado de servidor. Obtenga la cadena correcta de la CA emisora.
• Certificado caducado: no lo implemente. Solicite un certificado vigente y compruebe si un certificado intermedio o raíz de la cadena ha caducado. Zimbra documenta este modo de fallo en su guía de solución de problemas de certificados raíz caducados .
• Falta el nombre de host: la verificación puede no ser la misma que la que realiza un navegador. Inspeccione los SAN emitidos y vuelva a emitirlos si el nombre público no está presente.

Paso 5: implementar el certificado comercial

Solo después de que la verificación sea exitosa, deberá implementarlo:

/opt/zimbra/bin/zmcertmgr deploycrt comm /tmp/commercial.crt /tmp/ca_chain.crt

El proceso de implementación documentado de Zimbra copia el certificado comercial en su área SSL, agrega la cadena de CA, actualiza la configuración del certificado e instala el material del certificado para servicios como los componentes MTA, LDAP, proxy y buzón de correo, según corresponda al servidor.

No sobrescriba manualmente los almacenes de claves Java ni los archivos de certificados de servicio, a menos que la documentación de su versión específica de Zimbra lo requiera. El objetivo es zmcertmgrmantener la coherencia del material de certificado específico del servicio.

Paso 6: reiniciar los servicios de Zimbra

Tras la implementación, reinicie Zimbra:

su - zimbra
zmcontrol restart

Luego, verifique el estado del servicio:

zmcontrol status

Si un servicio no regresa a su estado inicial Running, investigue antes de declarar que el cambio de certificado se ha completado. Los problemas con los certificados pueden afectar a LDAP, el proxy, el buzón de correo u otras comunicaciones dependientes de TLS, especialmente en instalaciones de varios nodos.

Paso 7: verificar el resultado tanto en Zimbra como en el lado del cliente.

Utilice primero la vista de certificados propia de Zimbra:

/opt/zimbra/bin/zmcertmgr viewdeployedcrt

También puede comprobar si algún certificado de servicio implementado está próximo a caducar:

/opt/zimbra/bin/zmcertmgr checkcrtexpiration all -days 30

Finalmente, compruebe el nombre de host público exacto que utilizan los usuarios. Una comprobación útil de OpenSSL desde otra máquina es:

openssl s_client -connect mail.example.com:443 -servername mail.example.com -showcerts

Busque el certificado hoja esperado, el nombre de host correcto, una cadena completa y un resultado de verificación exitoso. Luego, abra la misma URL HTTPS en un navegador abierto. La prueba en el navegador es importante porque comprueba el nombre de host al que acceden los usuarios, no solo los archivos de certificado en el disco.

Cuando el procedimiento estándar no es suficiente

Si se cumple alguna de estas condiciones, cambie su enfoque en lugar de forzar los pasos de nodo único:

• Zimbra multinodo: la implementación de certificados puede requerir cubrir las funciones de proxy, buzón de correo, LDAP y MTA en distintos hosts. La herramienta de certificados de Zimbra admite opciones multiservidor, pero verifique el procedimiento para su topología antes de utilizarlas.
• El proxy inverso o el balanceador de carga externo finaliza la conexión TLS: es posible que también sea necesario instalar el certificado público en ese dispositivo. Un certificado Zimbra correcto por sí solo no modificará lo que ven los clientes si la conexión TLS finaliza en la ruta de origen.
• Está importando una clave existente: asegúrese de que esté ubicada donde Zimbra espera la clave privada comercial y de que los permisos coincidan con los requisitos de la versión antes de la verificación.
• Tu CA solo proporciona un paquete intermedio: sigue las instrucciones de la cadena actual de la CA en lugar de crear un certificado raíz. Zimbra necesita una cadena que pueda validar; los archivos exactos dependen del emisor.
• El certificado se renovó con el mismo nombre de host pero con una clave diferente: actualice la clave privada correspondiente antes de la verificación. Un certificado anterior commercial.keyno puede validar un certificado emitido para un nuevo par de claves.

Autocomprobación final

La instalación se considera completa solo cuando se cumplen todas las siguientes condiciones: verifycrtse ejecuta deploycrtcorrectamente, los servicios de Zimbra vuelven al estado "En ejecución", viewdeployedcrtse muestra el nuevo certificado y una conexión TLS externa al nombre de host real recibe el mismo certificado válido sin ninguna advertencia de confianza o nombre de host.

Para la sintaxis de los comandos y el comportamiento específico de cada versión, consulte la documentación oficial de las herramientas de certificados de Zimbra como referencia principal. Los ejemplos que se muestran aquí son mail.example.comsolo un marcador de posición; reemplace los nombres, los archivos de certificado y los detalles de la organización con los valores emitidos para su entorno.