Introdução
Este documento descreve como criar, configurar e solucionar problemas de certificados TLS no Cisco Email Security Appliance (ESA).
Pré-requisitos
Requisitos
Não existem requisitos específicos para este documento.
Componentes Utilizados
As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.
Informações de Apoio
A implementação do TLS no ESA fornece privacidade para transmissão ponto a ponto de e-mails através de criptografia. Esta implementação permite que um administrador importe um certificado e uma chave privada de um serviço de Autoridade de Certificação (CA) ou use um certificado autoassinado.
O Cisco AsyncOS para Email Security oferece suporte à extensão STARTTLS para SMTP (Simple Mail Transfer Protocol) (Secure SMTP over TLS).
Note: Este documento descreve como instalar certificados no nível de cluster com o uso do recurso de gerenciamento centralizado no ESA. Os certificados podem ser aplicados ao nível da máquina; no entanto, se a máquina for removida do cluster e adicionada novamente, os certificados no nível da máquina serão perdidos.
Visão geral funcional e requisitos
Um administrador pode utilizar um certificado no equipamento por qualquer um destes motivos:
- Para criptografar as conversações SMTP com outros MTAs que usam TLS (conversações de entrada e de saída).
- Para ativar o serviço HTTPS no equipamento para acesso à GUI via HTTPS.
- Para uso como um certificado de cliente para LDAPs (Lightweight Diretory Access Protocols), se o servidor LDAP exigir um certificado de cliente.
- Para permitir a comunicação segura entre o dispositivo e um dispositivo Cisco Advanced Malware Protection (AMP) Threat Grid.
O ESA vem pré-configurado com um certificado de demonstração que pode ser usado para estabelecer conexões TLS.
Caution: Embora o certificado de demonstração seja suficiente para o estabelecimento de uma conexão TLS segura, lembre-se de que ele não pode oferecer uma conexão verificável. A Cisco recomenda que você obtenha um certificado X.509 ou Privacy Enhanced Email (PEM) de uma CA.
Configurar e atribuir um certificado
Antes de continuar, certifique-se de ter concluído as etapas de criação e atribuição de um certificado, conforme descrito no Guia do usuário. Esses links fornecem as instruções necessárias:
Verificar
Verificar TLS para HTTPS
1. Acesse a GUI: Navegue até o dispositivo ESA usando o URL HTTPS (por exemplo, https://esa.example.com)
2. Abrir Detalhes do Certificado: Clique no ícone Informações do Site (geralmente um cadeado) localizado à esquerda do URL na barra de endereços do navegador.
3. Validar com base no seu Navegador:
a. Google Chrome: Clique no ícone Padlock > A conexão é segura > O certificado é válido.
b. Microsoft Edge: Clique no ícone Padlock > Connection is secure > Ícone do certificado (canto superior direito do submenu).
c. Mozilla Firefox: Clique no ícone Padlock > Connection secure > Mais informações > Exibir certificado.
4. Confirmar Validade: Revise o "Período de Validade" ou "Status" no visualizador de certificados. Se o certificado mostrar asValid, a conexão é segura e o certificado é reconhecido corretamente pelo navegador.
Verificar TLS para entrega ou recebimento de e-mail
Embora o Rastreamento de mensagens na GUI forneça essas informações, o uso da Interface de linha de comando (CLI) é frequentemente mais eficiente para revisão em massa ou solução rápida de problemas.
Siga estas etapas para revisar o status TLS através da CLI:
- Faça login na CLI: Acesse o equipamento via SSH usando suas credenciais administrativas.
- Execute o comando Grep: Use o greputility para filtrar os logs de e-mail para atividades relacionadas ao TLS.
- Analisar IDs de Conexão: revise a saída com base no tipo de conexão:
- ICID (ID da conexão de entrada): revise essas entradas para verificar se há conexões TLS recebidas no ouvinte.
- DCID (Delivery Connection ID, ID de conexão de entrega): revise essas entradas para verificar o TLS para conexões entregues ao MTA do próximo salto.
Note: Você pode procurar por strings específicas como "Êxito do TLS" ou "Falha do TLS" para restringir os resultados.
Exemplo de sucesso TLS ao receber e-mails
(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')
Exemplo de falha de TLS ao receber e-mails
(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
Exemplo de sucesso de TLS ao entregar e-mail
(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
Exemplo de falha de TLS ao entregar correio
(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
Embora os logs ldap_debug não mostrem uma string TLS específica, podemos determinar se o TLS foi bem-sucedido ou falhou examinando a resposta LDAP e as portas em uso. Para conexões LDAPS, isso geralmente significa a porta 3269 para Ative Diretory ou a porta 636 para OpenLDAP.
Exemplo 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
Note: Para uma análise mais detalhada do tráfego LDAP e da atividade TLS, recomendamos a captura de pacotes de rede nos hosts e portas relevantes.
Troubleshooting
Esta seção descreve como solucionar problemas básicos de TLS no ESA.
Verificar certificados intermediários
Procure certificados intermediários duplicados, especialmente quando os certificados atuais são atualizados em vez de criar um novo certificado. Os certificados intermediários podem ser alterados ou encadeados incorretamente, e o certificado pode carregar vários certificados intermediários. Isso pode introduzir problemas de verificação e encadeamento de certificados.
Habilitar notificações para falhas de conexão TLS necessárias
Você pode configurar o ESA para enviar um alerta se a negociação TLS falhar quando as mensagens forem entregues a um domínio que exija uma conexão TLS. A mensagem de alerta contém o nome do domínio de destino para a negociação TLS que falhou. O ESA envia a mensagem de alerta a todos os destinatários definidos para receber alertas de nível de gravidade de aviso para tipos de alerta do sistema.
Note: Essa é uma configuração global, portanto, não pode ser definida por domínio.
Conclua estas etapas para ativar os alertas de conexão TLS:
- Navegue até Políticas de e-mail > Controles de destino.
- Clique em Edit Global Settings.
- Marque a caixa de seleção Enviar um alerta quando uma conexão TLS necessária falhar.
Tip: Você também pode definir essa configuração com o comando CLI destconfig > setup.
O ESA também registra as instâncias para as quais o TLS é necessário para um domínio, mas não pode ser usado no aplicativo mail_logs. Isso ocorre quando qualquer uma destas condições é atendida:
- O MTA remoto não suporta ESMTP (por exemplo, ele não entendeu o comando EHLO do ESA).
- O MTA remoto suporta ESMTP, mas o comando STARTTLS não estava na lista de extensões anunciadas na resposta EHLO.
- O MTA remoto anunciou a extensão STARTTLS, mas respondeu com um erro quando o ESA enviou o comando STARTTLS.
Solução de problemas com ferramentas de terceiros
- Certifique-se de que o certificado seja aplicado no ouvinte onde o equipamento recebe e-mails de entrada antes de iniciar o teste.
As ferramentas de terceiros, como CheckTLS.com e SSL-Tools.net podem ser usadas para verificar o encadeamento adequado do certificado ao receber. Revise a documentação de cada ferramenta para entender como validar o certificado.
Note: Se um certificado autoassinado estiver em uso, uma falha será esperada.
Resolução
Se um certificado assinado por uma CA estiver em uso e a verificação TLS falhar, verifique se estes itens correspondem:
- Nome comum do certificado
- Nome do host (em GUI > Rede > Interface)
- Nome de host do registro MX: esta é a coluna Servidor MX na tabela TestReceiver.
Informações Relacionadas