Seguridad : Cisco Email Security Appliance

Asegúrese de que su certificado ESA pueda ser verificado

25 Agosto 2015 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (23 Abril 2015) | Comentarios

Introducción

Este documento describe cómo asegurarse de que su certificado del dispositivo de seguridad del correo electrónico de Cisco (ESA) puede ser verificado.

Contribuido por los ingenieros de Cisco TAC.

Procedimiento

Con el correo procesando con Cisco ESA, otros dominios pueden verificar a veces su certificado cuando le envían el correo (e.g. si utilizan algo similar a TLS “requerido”). Cuando ese dominio verifica su certificado, todos los controles deben tener éxito (en los ambos lados). Incluso si un control falla, la conexión TLS entera fallará. Es mejor práctica tener su certificado comprobable, incluso si usted está verificando otros dominios (e.g si usted está utilizando TLS “requerido”, “Requerir-verifique”, o “Preferir-verifique” en los controles del destino). La información en este artículo explica los puntos de verificación básicos para cubrir para saber si su certificado puede ser verificado con éxito.

Antes de explicar el proceso de verificación del certificado real es importante para primero entiende qué puede suceder en el nivel de la conexión:

El mail server de envío búsqueda de DNS el dominio de recepción para los expedientes MX (nombres de host). El mail server de envío entonces búsqueda de DNS el nombre de host del mail server de recepción para su dirección IP (el nombre de host con la prioridad más baja DNS). Muy probablemente, el servidor de envío búsqueda de DNS reversible esa dirección IP verá si vuelve el mismo nombre de host que volvió en la búsqueda de DNS original. Si el servidor de envío está verificando el dominio de recepción y no vuelve el mismo nombre de host, después el remitente caerá probablemente la conexión.

Los puntos de verificación básicos para verificar un certificado se muestran aquí:

  1. Si la conexión tiene éxito, después el mail server de recepción enviará un banner. El banner consistirá en el nombre del host real del mail server de recepción (220-mailhost.example.com). El mail server de envío recordará este nombre de host para cuando su hora de verificar el certificado. El mail server de envío enviará un comando EHLO junto con su propio dominio como argumento (e.g.ehloesa.com). El mail server de recepción responderá con sus parámetros, y el comando STARTTLS que está ofreciendo.

    Nota: Si usted hace una prueba manual telnet en el puerto 25 a un mail server de recepción y usted no ve que STARTTLS está ofrecido, después ese mail server no puede hacer TLS.

    El servidor de envío debe entonces realizar el comando STARTTLS. El mail server de recepción dirá “va a continuación con 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. Los dos servidores del correo decidirán sobre una fuerza de la cifra primero. Después de esto, el mail server de envío comenzará a verificar el certificado del mail server de recepción. 
  3. El servidor de envío verá el Common Name del certificado. El mail server de envío marcará este Common Name para considerar si hace juego (exactamente) el nombre de host del banner de la conexión (220-mailhost.example.com). Observe por favor que si usted tiene una placa comodín como su Common Name en el certificado (e.g *.example.com), después éste no hace juego exactamente el nombre de host en el banner (mailhost.example.com no hace juego exactamente *.example.com).  Si el Common Name del certificado no hace juego exactamente el nombre de host en este banner 220, después este control fallará. Por lo tanto, la conexión TLS fallará.
  4. El control básico más reciente se hace que está verificando que el certificado está encadenado correctamente. Algunos servidores de envío del correo no les gustan los certificados autofirmados. También, algunos servidores de envío del correo no les gustan los Certificados que han sido firmados por un Certificate Authority (CA) desconocido (CA que el mail server del remitente no conoce). Si el servidor de envío no le gusta su certificado autofirmado o no conoce quién es su CA, después TLS fallará.
  5. Otra pieza a verificar el encadenamiento de su certificado es considerar si su certificado del dominio (compañía) se puede enlazar de nuevo a su Certificate Authority (CA). Generalmente, si usted comprara un certificado de CA, después usted tendría un certificado de la compañía, el certificado intermedio, y un certificado de la raíz (CA) (usted puede haber recibido en algunos casos solamente un certificado, pero este un certificado debe todavía contener los tres). Estos tres Certificados se deben por separado (pero todavía cargar correctamente en el ESA en la misma red > Certificados localizados página). Si usted no tiene tres Certificados cargados al ESA por separado (o en la orden apropiada), después el mail server de envío no podrá verificar que usted tiene un certificado correctamente encadenado. Por lo tanto, TLS fallará.

    Si el servidor de envío está verificando su certificado y los controles antedichos uces de los fallan, después TLS fallará.

Información Relacionada


Discusiones relacionadas de la comunidad de soporte de Cisco

La Comunidad de Soporte de Cisco es un foro donde usted puede preguntar y responder, ofrecer sugerencias y colaborar con colegas.


Document ID: 118572