Sécurité : Appareil de sécurité de courriel Cisco

Assurez-vous que votre certificat ESA peut être vérifié

17 décembre 2015 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires

Introduction

Ce document décrit comment s'assurer que votre certificat des appareils de sécurité du courrier électronique de Cisco (ESA) peut être vérifié.

Contribué par des ingénieurs TAC Cisco.

Procédure

Avec la messagerie traitant par Cisco ESA, parfois d'autres domaines peuvent vérifier votre certificat quand ils t'envoient la messagerie (par exemple. S'ils les utilisent quelque chose semblable au TLS « a exigé »). Quand ce domaine vérifie votre certificat, tous les contrôles doivent réussir (des deux côtés). Même si un contrôle échoue, la connexion entière de TLS échouera. Il est dans pratique recommandée d'avoir votre certificat vérifiable, même si vous vérifiez d'autres domaines (par exemple si vous utilisez le TLS « prié », « Exiger-vérifiez », ou « Préférer-vérifiez » dans des contrôles de destination). L'information dans l'article explique les points de reprise de base pour couvrir afin de savoir si votre certificat peut être avec succès vérifié.

Avant d'expliquer le processus de vérification réel de certificat il est important pour d'abord comprennent ce qui peut se produire au niveau de connexion :

Le serveur de messagerie de envoi consultation de DN le domaine de réception pour les enregistrements MX (adresses Internet). Le serveur de messagerie de envoi alors consultation de DN l'adresse Internet du serveur de réception des messages pour son adresse IP (l'adresse Internet avec la plus basse priorité de DN). Très probablement, le serveur de envoi renversera la consultation de DN cette adresse IP pour voir si elle renvoie la même adresse Internet qu'elle a renvoyée dans la consultation d'origine de DN. Si le serveur de envoi vérifie le domaine de réception et il ne renvoie pas la même adresse Internet, alors l'expéditeur probablement arrêter la connexion.

Les points de reprise de base pour vérifier un certificat sont affichés ici :

  1. Si la connexion réussit, alors le serveur de réception des messages enverra une bannière. La bannière comprendra l'adresse Internet réelle du serveur de réception des messages (220-mailhost.example.com). Le serveur de messagerie de envoi se souviendra cette adresse Internet pour quand son heure de vérifier le certificat. Le serveur de messagerie de envoi enverra une commande EHLO avec son propre domaine comme argument (e.g.ehloesa.com). Le serveur de réception des messages répondra avec ses paramètres, et la commande STARTTLS qu'il offre.

    Remarque: Si vous faites un test manuel de telnet sur le port 25 à un serveur de réception des messages et vous ne voyez pas que STARTTLS est offert, alors ce serveur de messagerie ne peut pas faire le TLS.

    Le serveur de envoi doit alors exécuter la commande STARTTLS. Le serveur de réception des messages dira que « allez en avant avec le 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. Les deux serveurs de messagerie décideront d'un point fort de chiffrement d'abord. Après ceci, le serveur de messagerie de envoi commencera à vérifier le certificat du serveur de réception des messages. 
  3. Le serveur de envoi verra le nom commun du certificat. Le serveur de messagerie de envoi vérifiera ce nom commun pour voir s'il apparie (exactement) l'adresse Internet de la bannière de connexion (220-mailhost.example.com). Veuillez noter que si vous avez un caractère générique en tant que votre nom commun dans le certificat (par exemple *.example.com), alors ceci n'apparie pas exactement l'adresse Internet dans la bannière (mailhost.example.com n'apparie pas exactement *.example.com).  Si le nom commun du certificat n'apparie pas exactement l'adresse Internet dans cette bannière 220, alors ce contrôle échouera. Par conséquent, la connexion de TLS échouera.
  4. Le dernier contrôle de base qui est fait vérifie que le certificat est correctement enchaîné. Quelques serveurs de messagerie de envoi n'aiment pas les Certificats Auto-signés. En outre, quelques serveurs de messagerie de envoi n'aiment pas les Certificats qui ont été signés par un Autorité de certification (CA) inconnu (un CA que le serveur de messagerie d'expéditeur ne connaît pas). Si le serveur de envoi n'aime pas votre certificat Auto-signé ou ne sait pas qui votre CA est, alors le TLS échouera.
  5. Une autre pièce à vérifier la chaîne de votre certificat est de voir si votre certificat de domaine (société) peut être joint de nouveau à votre Autorité de certification (CA). Généralement, si vous achetiez un certificat d'un CA, puis vous auriez un certificat de société, le certificat intermédiaire, et un certificat de la racine (CA) (dans certains cas vous pouvez avoir seulement reçu un certificat, mais ce un certificat devrait encore contenir chacun des trois). Ces trois Certificats devraient être correctement téléchargés séparément (mais toujours dans l'ESA sur le mêmes réseau > Certificats localisés par page). Si vous n'avez pas chacun des trois Certificats téléchargés à l'ESA séparément (ou dans la commande appropriée), alors le serveur de messagerie de envoi ne pourra pas vérifier que vous avez un certificat correctement enchaîné. Par conséquent, le TLS échouera.

    Si le serveur de envoi vérifie votre certificat et les contrôles ci-dessus l'uns des échouent, alors le TLS échouera.

Informations connexes


Conversations connexes de la communauté de soutien de Cisco

Le site Cisco Support Community est un forum où vous pouvez poser des questions, répondre à des questions, faire part de suggestions et collaborer avec vos pairs.


Document ID: 118572