Verificar y solucionar problemas de certificados TLS en Cisco ESA

Introducción

Este documento describe cómo crear, configurar y resolver problemas de certificados TLS en el dispositivo de seguridad Cisco Email Security Appliance (ESA).

Prerequisites

Requirements

No hay requisitos específicos para este documento.

Componentes Utilizados

La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.

Antecedentes

La implementación de TLS en el ESA proporciona privacidad para la transmisión punto a punto de correos electrónicos a través del cifrado. Esta implementación permite a un administrador importar un certificado y una clave privada de un servicio de Autoridad de certificados (CA) o utilizar un certificado autofirmado.

Cisco AsyncOS para Email Security admite la extensión STARTTLS del protocolo simple de transferencia de correo (SMTP) (SMTP seguro sobre TLS).

Nota: Este documento describe cómo instalar certificados en el nivel de clúster con el uso de la función de administración centralizada en el ESA. Los certificados pueden aplicarse a nivel de máquina; sin embargo, si se quita la máquina del clúster y, a continuación, se vuelve a agregar, se pierden los certificados de nivel de máquina.

Descripción general funcional y requisitos

Un administrador puede utilizar un certificado en el dispositivo por cualquiera de estos motivos:

• Para cifrar las conversaciones SMTP con otros MTA que utilizan TLS (conversaciones entrantes y salientes).
• Para habilitar el servicio HTTPS en el dispositivo para el acceso a la GUI a través de HTTPS.
• Para su uso como certificado de cliente para protocolos ligeros de acceso a directorios (LDAP), si el servidor LDAP requiere un certificado de cliente.
• Para permitir una comunicación segura entre el dispositivo y un dispositivo Threat Grid de protección frente a malware avanzado (AMP) de Cisco.

El ESA viene preconfigurado con un certificado de demostración que se puede utilizar para establecer conexiones TLS.

Precaución: Aunque el certificado de demostración es suficiente para establecer una conexión TLS segura, tenga en cuenta que no puede ofrecer una conexión verificable. Cisco recomienda que obtenga un certificado X.509 o de Correo electrónico con privacidad mejorada (PEM) de una CA.

Configurar y asignar un certificado

Antes de continuar, asegúrese de haber completado los pasos para crear y asignar un certificado como se describe en la guía del usuario. Estos enlaces proporcionan las instrucciones necesarias:

• Implementar un certificado firmado
• Asignación de un certificado

Verificación

Verificar TLS para HTTPS

1. Acceder a la GUI: Navegue hasta su dispositivo ESA usando la URL HTTPS (por ejemplo, https://esa.example.com)

2. Detalles del certificado abierto: Haga clic en el icono Información del sitio (normalmente un candado) situado a la izquierda de la URL en la barra de direcciones del navegador.

3. Validar basándose en su navegador:

     a. Google Chrome: Haga clic en el icono Candado > La conexión es segura > El certificado es válido.

     b. Microsoft Edge: Haga clic en el icono de candado > Connection is secure > Certificate icon (parte superior derecha del menú desplegable).

     c. Mozilla Firefox: Haga clic en el icono Candado > Conexión segura > Más información > Ver certificado.

4. Confirmar validez: Revise el "Período de Validez" o "Estado" en el visor de certificados. Si el certificado aparece como Válido, la conexión es segura y el explorador reconoce correctamente el certificado.

Verificar TLS para entrega o recepción de correo electrónico

Aunque Rastreo de mensajes en la GUI proporciona esta información, el uso de la Interfaz de línea de comandos (CLI) es a menudo más eficiente para la revisión masiva o la resolución rápida de problemas.

Siga estos pasos para revisar el estado de TLS mediante la CLI:

1. Inicie sesión en la CLI: acceda al dispositivo a través de SSH utilizando sus credenciales administrativas.
2. Ejecute el comando Grep: Use la greputility para filtrar los registros de correo para actividad relacionada con TLS.
3. Analizar ID de conexión: revise la salida según el tipo de conexión:
   • ICID (ID de conexión entrante): revise estas entradas para verificar que TLS no tenga conexiones recibidas en el receptor.
   • DCID (ID de conexión de entrega): revise estas entradas para verificar TLS para las conexiones que se envían al MTA de salto siguiente.

Nota: Puede buscar cadenas específicas como "TLS correcto" o "TLS erróneo" para restringir los resultados.

Ejemplo de éxito de TLS al recibir correo

(Machine esa.example.com)> grep "ICID.*TLS failed" mail_logs
Sat Feb 14 19:20:28 2026 Info: ICID 111396123 TLS failed: [Errno 0] Error
Sat Feb 14 19:20:28 2026 Info: ICID 111396456 TLS failed: ('SSL routines:tls_early_post_process_client_hello:no shared cipher')

Ejemplo de falla de TLS al recibir correo

(Machine esa.example.com)> grep "ICID.*TLS success" mail_logs
Sat Feb 14 19:14:38 2026 Info: ICID 111395123 TLS success protocol TLSv1.2 cipher ECDHE-RSA-AES256-GCM-SHA384
Sat Feb 14 19:14:41 2026 Info: ICID 111395456 TLS success protocol TLSv1.3 cipher TLS_AES_256_GCM_SHA384

Ejemplo de éxito de TLS al entregar correo

(Machine esa.example.com)> grep "DCID.*TLS success" mail_logs

Sat Feb 14 19:12:56 2026 Info: DCID 21966123 TLS success protocol TLSv1.2 cipher ECDHE-RSA-AES256-GCM-SHA384 the.cpq.host
Sat Feb 14 19:13:00 2026 Info: DCID 21966456 TLS success protocol TLSv1.3 cipher TLS_AES_256_GCM_SHA384

Ejemplo de falla de TLS al entregar correo

(Machine esa.example.com)> grep "DCID.*TLS failed" mail_logs

Sat Feb 14 19:58:43 2026 Info: DCID 21967123 TLS failed: TLS required, STARTTLS unavailable, destination is TLS disabled
Sat Feb 14 20:58:44 2026 Info: DCID 21967456 TLS failed: TLS required, STARTTLS unavailable, destination is TLS disabled

Verificar TLS para LDAP

Aunque los registros ldap_debug no muestran una cadena TLS específica, podemos determinar si TLS es exitoso o ha fallado examinando la respuesta LDAP y los puertos en uso. Para las conexiones LDAPS, esto normalmente significa el puerto 3269 para Active Directory o el puerto 636 para OpenLDAP.

Ejemplo de TLS para LDAP

(Machine esa.example.com) (SERVICE)> tail ldap_debug

Wed Feb 25 03:24:23 2026 Debug: LDAP: (group) Query (proxyAddresses=smtp:user@example.com) to server LDAP (ldaps-esa.example.com:3269)
Wed Feb 25 03:24:23 2026 Debug: LDAP: (group) Query (proxyAddresses=smtp:user@example.com) lookup success, (ldaps-esa.example.com:3269) returned 0 results timestamp=1771989863.189580

Nota: Para un análisis más detallado del tráfico LDAP y la actividad TLS, se recomienda capturar paquetes de red en los hosts y puertos relevantes.

Troubleshoot

Esta sección describe cómo resolver problemas básicos de TLS en el ESA.

Comprobar certificados intermedios

Busque certificados intermedios duplicados, especialmente cuando se actualizan los certificados actuales en lugar de crear un nuevo certificado. Los certificados intermedios pueden cambiar o encadenarse incorrectamente, y el certificado puede cargar varios certificados intermedios. Esto puede introducir problemas de encadenamiento y verificación de certificados.

Habilitar notificaciones para errores de conexión TLS requeridos

Puede configurar el ESA para enviar una alerta si la negociación TLS falla cuando se entregan mensajes a un dominio que requiere una conexión TLS. El mensaje de alerta contiene el nombre del dominio de destino para la negociación TLS fallida. El ESA envía el mensaje de alerta a todos los destinatarios configurados para recibir alertas de nivel de gravedad de advertencia para los tipos de alerta del sistema.

Nota: Se trata de una configuración global, por lo que no se puede establecer por dominio.

Complete estos pasos para habilitar las alertas de conexión TLS:

1. Vaya a Políticas de correo > Controles de destino.
2. Haga clic en Edit Global Settings.
3. Marque la casilla de verificación Enviar una alerta cuando falle una conexión TLS obligatoria.

Consejo: También puede configurar esta configuración con el comando destconfig > setup CLI.

El ESA también registra las instancias para las cuales se requiere TLS para un dominio, pero no se pudo utilizar en el dispositivo mail_logs. Esto ocurre cuando se cumple cualquiera de estas condiciones:

• El MTA remoto no soporta ESMTP (por ejemplo, no entendió el comando EHLO del ESA).
• El MTA remoto soporta ESMTP, pero el comando STARTTLS no estaba en la lista de extensiones anunciadas en la respuesta EHLO.
• El MTA remoto anunció la extensión STARTTLS, pero respondió con un error cuando el ESA envió el comando STARTTLS.

Solución de problemas mediante herramientas de terceros

• Asegúrese de que el certificado se aplica en el Receptor donde el dispositivo recibe correo entrante antes de comenzar la prueba.

Las herramientas de terceros como CheckTLS.com y SSL-Tools.net se pueden utilizar para verificar el correcto encadenamiento del certificado durante la recepción. Revise la documentación de cada herramienta para saber cómo validar el certificado.

Nota: Si se está utilizando un certificado autofirmado, se espera un error.

Resolución

Si un certificado firmado por la CA está en uso y falla la verificación de TLS, verifique que estos elementos coincidan:

• Nombre común del certificado
• Nombre de host (en GUI > Red > Interfaz)
• Nombre de host del registro MX: columna Servidor MX de la tabla TestReceiver.

Información Relacionada

• Dispositivo de seguridad Cisco Email Security Appliance: guías del usuario final