Segurança : Cisco Email Security Appliance

Assegure-se de que seu certificado ESA possa ser verificado

19 Setembro 2015 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (22 Agosto 2015) | Feedback

Introdução

Este documento descreve como assegurar-se de que seu Cisco envie por correio eletrónico o certificado da ferramenta de segurança (ESA) possa ser verificado.

Contribuído por engenheiros de TAC da Cisco.

Procedimento

Com o correio que processa através de Cisco ESA, às vezes outros domínios podem verificar seu certificado quando lhe enviam o correio (por exemplo. Se se usam algo similar ao TLS “exigiu”). Quando esse domínio verifica seu certificado, todas as verificações devem suceder (em ambos os lados). Mesmo se uma verificação falha, a conexão TLS inteira falhará. É melhor prática ter seu certificado passível de verificação, mesmo se você está verificando outros domínios (por exemplo se você está usando o TLS “exigido”, “Exigir-verifique”, ou “Preferir-verifique” em controles do destino). A informação neste artigo explica os pontos de verificação básicos para cobrir a fim saber se seu certificado pode com sucesso ser verificado.

Antes de explicar o processo de verificação de certificado real é importante para primeiramente compreende o que pode acontecer a nível da conexão:

O mail server de emissão pesquisa de DNS o domínio de recepção para os registros MX (nomes de host). O mail server de emissão então pesquisa de DNS o hostname do mail server de recepção para seu endereço IP de Um ou Mais Servidores Cisco ICM NT (o hostname com a mais baixa prioridade DNS). Muito provavelmente, o server de emissão pesquisa de DNS reversa esse endereço IP de Um ou Mais Servidores Cisco ICM NT verá se retorna o mesmo hostname que retornou na pesquisa de DNS original. Se o server de emissão está verificando que o domínio e de recepção não retornam o mesmo hostname, a seguir o remetente deixará cair provavelmente a conexão.

Os pontos de verificação básicos para verificar um certificado são mostrados aqui:

  1. Se a conexão sucede, a seguir o mail server de recepção enviará uma bandeira. A bandeira consistirá no nome de host real do mail server de recepção (220-mailhost.example.com). O mail server de emissão recordará este hostname para quando sua hora de verificar o certificado. O mail server de emissão enviará um comando EHLO junto com seu próprio domínio como um argumento (e.g.ehloesa.com). O mail server de recepção responderá com seus parâmetros, e o comando STARTTLS que está oferecendo.

    Nota: Se você faz um teste manual do telnet na porta 25 a um mail server de recepção e você não vê que STARTTLS está oferecido, a seguir esse mail server não pode fazer o TLS.

    O server de emissão deve então executar o comando STARTTLS. O mail server de recepção dirá que “vá adiante com TLS”.

    myesa.local> telnet mailhost.example.com 25
    Trying 1.1.1.1...
    Connected to mailhost.example.com.
    Escape character is '^]'.
    220-mailhost.example.com ESMTP
    220 Welcome to this mail server. You may proceed to communicate.
     
    ehlo esa.com
    250-mailhost.example.com
    250-8BITMIME
    250-SIZE 33554432
    250 STARTTLS
     
    starttls
    220 Go ahead with TLS
  2. Os dois server do correio decidirão em uma força da cifra primeiramente. Após isto, o mail server de emissão começará a verificar o certificado do mail server de recepção. 
  3. O server de emissão verá o Common Name do certificado. O mail server de emissão verificará este Common Name para considerar se combina (exatamente) o hostname da bandeira da conexão (220-mailhost.example.com). Note por favor que se você tem uma curinga como seu Common Name no certificado (por exemplo *.example.com), a seguir este não combina exatamente o hostname na bandeira (mailhost.example.com não combina exatamente *.example.com).  Se o Common Name do certificado não combina exatamente o hostname nesta bandeira 220, a seguir esta verificação falhará. Consequentemente, a conexão TLS falhará.
  4. A última verificação básica que é feita está verificando que o certificado está acorrentado corretamente. Alguns server de emissão do correio não gostam de certificados auto-assinados. Também, alguns server de emissão do correio não gostam dos Certificados que foram assinados por um Certificate Authority (CA) desconhecido (CA que o mail server do remetente não conhece). Se o server de emissão não gosta de seu certificado auto-assinado ou não conhece quem seu CA é, a seguir o TLS falhará.
  5. Uma outra peça a verificar a corrente de seu certificado é considerar se seu certificado do domínio (empresa) pode ser ligado de volta a seu Certificate Authority (CA). Geralmente, se você comprou um certificado de CA, a seguir você teria um certificado da empresa, o certificado intermediário, e um certificado da raiz (CA) (em alguns casos você pode somente ter recebido um certificado, mas este um certificado deve ainda conter todos os três). Estes três Certificados devem corretamente ser transferidos arquivos pela rede no ESA separadamente (mas ainda na mesmos rede > Certificados encontrados página). Se você não tem todos os três Certificados transferidos arquivos pela rede até o ESA separadamente (ou na ordem apropriada), a seguir o mail server de emissão não poderá verificar que você tem um certificado corretamente acorrentado. Consequentemente, o TLS falhará.

    Se o server de emissão está verificando que seu certificado e algum das verificações acima falhe, a seguir o TLS falhará.

Informações Relacionadas


Discussões relacionadas da comunidade de suporte da Cisco

A Comunidade de Suporte da Cisco é um fórum onde você pode perguntar e responder, oferecer sugestões e colaborar com colegas.


Document ID: 118572