Guide complet d'installation pour le TLS sur l'ESA

Introduction

Ce document décrit comment créer un certificat pour l'usage avec le Transport Layer Security (TLS), lancer le TLS d'arrivée et sortant, et dépanner les questions de base de TLS sur l'appliance de sécurité du courrier électronique de Cisco (ESA).

Conditions préalables

Exigences

Aucune spécification déterminée n'est requise pour ce document.

Composants utilisés

Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.

Les informations contenues dans ce document ont été créées à partir des périphériques d'un environnement de laboratoire spécifique. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si votre réseau est opérationnel, assurez-vous que vous comprenez l'effet potentiel de toute commande.

Informations générales

L'implémentation de TLS sur l'ESA fournit l'intimité pour la transmission point par point des emails par le cryptage. Il permet à un administrateur pour importer un certificat et une clé privée d'un service d'Autorité de certification (CA), ou utilise un certificat auto-signé.

Cisco AsyncOS pour la sécurité du courrier électronique prend en charge l'extension STARTTLS au Protocole SMTP (Simple Mail Transfer Protocol) (SMTP sécurisé au-dessus de TLS).

Conseil : Pour plus d'informations sur le TLS, référez-vous à RFC 3207.

Remarque: Ce document décrit comment installer des Certificats au niveau de batterie avec l'utilisation de la fonctionnalité de gestion centralisée sur l'ESA. Les Certificats peuvent être appliqués au niveau d'ordinateur aussi bien ; cependant, si l'ordinateur est jamais retiré de la batterie et de retour alors ajouté, les Certificats niveau de l'ordinateur seront perdus.

Présentation fonctionnelle et conditions requises

Un administrateur pourrait désirer créer un certificat auto-signé sur l'appliance pour l'un de ces raisons :

• Afin de chiffrer les conversations de SMTP avec d'autres MTA qui utilisent le TLS (conversations d'arrivée et sortantes).
  
  
• Afin d'activer le service HTTPS sur l'appliance pour l'accès au GUI par l'intermédiaire de HTTPS.
  
  
• Pour l'usage comme certificat client pour des protocoles LDAP (LDAP), si le serveur LDAP a besoin d'un certificat client.
  
  
• Afin de permettre la communication protégée entre l'appliance et le gestionnaire d'entreprise de Rivest-Shamir-Addleman (RSA) pour la protection de perte de données (DLP).
  
  
• Afin de permettre la communication protégée entre l'appliance et Cisco a avancé l'appliance de grille de menace de protection de malware (AMP).

L'ESA est livré préconfiguré avec un certificat de démonstration qui peut être utilisé afin d'établir des connexions de TLS.

Attention : Tandis que le certificat de démonstration est suffisant pour l'établissement d'une connexion sécurisée de TLS, rendez-vous compte qu'elle ne peut pas offrir une connexion vérifiable.

Cisco recommande que vous obteniez un X.509, ou certificat de l'email amélioré par intimité (PEM) d'un CA. Ceci pourrait également désigné sous le nom d'un certificat d'Apache. Le certificat d'un CA est desirable au-dessus du certificat auto-signé parce qu'un certificat auto-signé est semblable au certificat précédemment mentionné de démonstration, qui ne peut pas offrir une connexion vérifiable.

Remarque: Le format de certificat PEM est encore défini dans RFC 1421 à RFC 1424. Le PEM est un format de conteneur qui peut inclure seulement le certificat public (comme avec Apache installe et fichier /etc/ssl/certs de certificat de CA) ou une chaîne de certificat entière, pour inclure la clé publique, la clé privée, et les certificats racine. Le PEM de nom est d'une méthode défectueuse pour l'email sécurisé, mais le format de conteneur qu'il a utilisé est toujours en activité et est une traduction base-64 des clés X.509 ASN.1.

Apportez votre propre certificat

L'option d'importer votre propre certificat est disponible sur l'ESA ; cependant, la condition requise est que le certificat soit dans le format PKCS#12. Ce format inclut la clé privée. Les administrateurs n'ont pas souvent des Certificats qui sont disponibles dans ce format. Pour cette raison, Cisco recommande que vous génériez le certificat sur l'ESA et le fassiez signer correctement par un CA.

Mettez à jour un certificat valable

Si un certificat qui existe déjà a expiré, ignorez la section Auto-signée la déployant de Certificats de ces document et re-signe le certificat qui existe.

Conseil : Référez-vous au renouveler un certificat sur un document Cisco d'appareils de sécurité du courrier électronique pour plus de détails.

Déployez les Certificats Auto-signés

Cette section décrit comment générer une demande auto-signée de certificat et de signature de certificat (CSR), fournir le certificat auto-signé à un CA pour signer, télécharger le certificat signé à l'ESA, spécifier le certificat pour l'usage avec les services ESA, et sauvegarder la configuration et les certificats d'appareils.

Générez un certificat et un CSR Auto-signés

Afin de créer un certificat auto-signé par l'intermédiaire du CLI, sélectionnez la commande de certconfig.

Terminez-vous ces étapes afin de créer un certificat auto-signé du GUI :

1. Naviguez vers le réseau > les Certificats > ajoutent le certificat du GUI d'appareils.
   
   
2. Cliquez sur le menu déroulant de certificat Auto-signé par création.
   
   Quand vous créez le certificat, assurez-vous que le nom commun apparie l'adresse Internet de l'interface de écoute, ou qu'il apparie l'adresse Internet de l'interface de la livraison.
   
   
   • L'interface de écoute est l'interface qui est liée à l'auditeur qui est configuré sous le réseau > les auditeurs.
     
     
   • L'interface de la livraison est automatiquement sélectionnée, à moins qu'explicitement configuré du CLI avec la commande de deliveryconfig.
3. Pour une connexion entrante vérifiable, validez que ces trois éléments s'assortissent :
   
   
   • MX Record (adresse Internet de Système de noms de domaine (DNS))
     
     
   • Nom commun
     
     
   • Adresse Internet d'interface

Remarque: L'adresse Internet de système n'affecte pas les connexions de TLS en vue d'être vérifiable. L'adresse Internet de système est affichée dans l'angle supérieur droit du GUI d'appareils, ou de la sortie de commande de sethostname CLI.

Attention : Souvenez-vous pour soumettre et commettre vos modifications avant que vous exportiez le CSR. Si ces étapes ne sont pas terminées, le nouveau certificat ne sera pas commis à la configuration d'appareils, et le certificat signé du CA ne peut pas signer, ou soit appliqué à, un certificat qui existe déjà.

Fournissez le certificat Auto-signé à un CA

Terminez-vous ces étapes afin de soumettre le certificat auto-signé à un CA pour la signature :

1. Sauvegardez le CSR à un ordinateur local demande de signature de certificat dans le réseau de format PEM > les Certificats > de certificat nom > téléchargement).
   
   
2. Envoyez le certificat généré à un CA identifié pour la signature.
   
   
3. Demandez par X.509/PEM/Apache un certificat formaté, aussi bien que le certificat intermédiaire.

Le CA génère alors un certificat dans le format PEM.

Remarque: Pour une liste de fournisseurs CA, référez-vous à l'article de Wikipedia d'autorité de certification.

Téléchargez le certificat signé à l'ESA

Après que le CA renvoie le certificat public de confiance qui est signé par une clé privée, vous devez télécharger le certificat signé à l'ESA. Le certificat peut alors être utilisé avec un auditeur public ou privé, un service de l'interface IP HTTPS, l'interface de LDAP, ou toutes les connexions sortantes de TLS aux domaines de destination.

Terminez-vous ces étapes afin de télécharger le certificat signé à l'ESA :

1. Assurez-vous que le certificat public de confiance qui est format reçu PEM d'utilisations, ou un format qui peut être converti en PEM avant que vous le téléchargiez à l'appliance.

   Conseil : Vous pouvez employer la boîte à outils d'OpenSSL, un programme de logiciel gratuit, afin de convertir le format.

2. Téléchargez le certificat signé :
   
   
   1. Naviguez vers le réseau > les Certificats.
      
      
   2. Cliquez sur le nom du certificat qui a été envoyé au CA pour la signature.
      
      
   3. Entrez dans le chemin au fichier sur le volume d'ordinateur local ou de réseau.

Remarque: Quand vous téléchargez le nouveau certificat, il remplace le certificat valable. Un certificat intermédiaire qui est lié au certificat auto-signé peut également être téléchargé.

Attention : Souvenez-vous pour soumettre et commettre les modifications après que vous téléchargiez le certificat signé.

Spécifiez le certificat pour l'usage avec des services ESA

Maintenant que le certificat est créé, signé, et téléchargé à l'ESA, il peut être utilisé pour les services qui exigent l'utilisation de certificat.

TLS d'arrivée

Terminez-vous ces étapes afin d'utiliser le certificat pour les services d'arrivée de TLS :

1. Naviguez vers le réseau > les auditeurs.
   
   
2. Cliquez sur le nom d'auditeur.
   
   
3. Sélectionnez le nom de certificat du menu déroulant de certificat.
   
   
4. Cliquez sur Submit.
   
   
5. Répétez les étapes 1 à 4 comme nécessaire pour tous les auditeurs supplémentaires.
   
   
6. Commettez les modifications.

TLS sortant

Terminez-vous ces étapes afin d'utiliser le certificat pour les services sortants de TLS :

1. Naviguez pour envoyer par mail des stratégies > des contrôles de destination.
   
   
2. Cliquez sur Edit les paramètres généraux… dans la section de paramètres généraux.
   
   
3. Sélectionnez le nom de certificat du menu déroulant de certificat.
   
   
4. Cliquez sur Submit.
   
   
5. Commettez les modifications.

HTTPS

Terminez-vous ces étapes afin d'utiliser le certificat pour les services HTTPS :

1. Naviguez vers le réseau > les interfaces IP.
   
   
2. Cliquez sur le nom d'interface.
   
   
3. Sélectionnez le nom de certificat du menu déroulant de certificat HTTPS.
   
   
4. Cliquez sur Submit.
   
   
5. Répétez les étapes 1 à 4 comme nécessaire pour toutes les interfaces supplémentaires.
   
   
6. Commettez les modifications.

LDAP

Terminez-vous ces étapes afin d'utiliser le certificat pour les LDAP :

1. Naviguez vers l'administration système > le LDAP.
   
   
2. Cliquez sur Edit les configurations… dans la section de paramètres généraux de LDAP.
   
   
3. Sélectionnez le nom de certificat du menu déroulant de certificat.
   
   
4. Cliquez sur Submit.
   
   
5. Commettez les modifications.

Filtrage des URL

Terminez-vous ces étapes afin d'utiliser le certificat pour le Filtrage URL :

1. Sélectionnez la commande de websecurityconfig dans le CLI.
   
   
2. Poursuivez par les invites de commande. Assurez-vous que vous sélectionnez Y quand vous atteignez cette demande :
   
   

   Do you want to set client certificate for Cisco Web Security Services Authentication?

3. Sélectionnez le nombre qui est associé avec le certificat.
   
   
4. Sélectionnez la commande de validation afin de commettre les modifications de configuration.

Sauvegardez la configuration et les certificats d'appareils

Assurez-vous que la configuration d'appareils est enregistrée à ce moment. La configuration d'appareils contient le travail terminé de certificat qui a été appliqué par l'intermédiaire des processus précédemment décrits.

Terminez-vous ces étapes afin de sauvegarder le fichier de configuration d'appareils :

1. Naviguez vers l'administration système > le fichier de configuration > le fichier téléchargé vers l'ordinateur local à visualiser ou sauvegarder.
   
   
2. Exportez le certificat :
   
   
   1. Naviguez vers le réseau > les Certificats.
      
      
   2. Certificat d'exportation de clic.
      
      
   3. Sélectionnez le certificat pour exporter.
      
      
   4. Écrivez le nom du fichier du certificat.
      
      
   5. Entrez un mot de passe pour le fichier du certificat.
      
      
   6. Exportation de clic.
      
      
   7. Sauvegardez le fichier à des gens du pays ou à un ordinateur du réseau.
      
      
   8. Des Certificats supplémentaires peuvent être exportés à ce moment, ou l'annulation de clic afin de retourner au réseau > délivre un certificat l'emplacement.

Remarque: Ce processus enregistre le certificat dans le format PKCS#12, qui crée et enregistre le fichier avec la protection par mot de passe.

Lancez le TLS d'arrivée

Afin de lancer le TLS pour toutes les sessions d'arrivée, connectez au GUI de Web, choisissez les stratégies de messagerie > les stratégies de flux de courrier pour l'auditeur d'arrivée configuré, et puis terminez-vous ces étapes :

1. Choisissez un auditeur pour lequel les stratégies doivent être modifiées.
   
   
2. Cliquez sur le lien pour le nom de la stratégie afin de l'éditer.
   
   
3. Dans les fonctionnalités de sécurité sectionnez, choisissez un de ces des options de cryptage et d'authentification afin de placer le niveau du TLS qui est exigé pour ces auditeur et stratégie de flux de courrier :
   
   
   • Outre de – Quand cette option est choisie, le TLS n'est pas utilisé.
     
     
   • Préféré – Quand cette option est choisie, le TLS peut négocier du distant MTA à l'ESA. Cependant, si le distant MTA ne négocie pas (avant la réception d'une réponse 220), la transaction de SMTP continue en clair (non chiffré). Aucune tentative n'est faite afin de vérifier si le certificat provient d'une autorité de certification de confiance. Si une erreur se produit après que la réponse 220 soit reçue, alors la transaction de SMTP ne retombe pas au texte clair.
     
     
   • Requis – Quand cette option est choisie, le TLS peut être négocié du distant MTA à l'ESA. Aucune tentative n'est faite afin de vérifier le certificat du domaine. Si la négociation échoue, aucun email n'est envoyé par la connexion. Si la négociation réussit, alors la messagerie est fournie par l'intermédiaire d'une session chiffrée.
4. Cliquez sur Submit.
   
   
5. Cliquez sur le bouton de modifications de validation. Vous pouvez ajouter un commentaire facultatif à ce moment, si désiré.
   
   
6. Modifications de validation de clic afin de sauvegarder les modifications.

La stratégie de flux de courrier pour l'auditeur est maintenant mise à jour avec les configurations de TLS que vous avez choisies.

Terminez-vous ces étapes afin de lancer le TLS pour les sessions d'arrivée qui arrivent d'un ensemble choisi de domaines :

1. Connectez au GUI de Web et choisissez les stratégies de messagerie > la vue d'ensemble de CHAPEAU.
   
   
2. Ajoutez les expéditeurs IP/FQDN au groupe approprié d'expéditeur.
   
   
3. Éditez les configurations de TLS de la stratégie de flux de courrier qui est associée avec le groupe d'expéditeur que vous avez modifié dans l'étape précédente.
   
   
4. Cliquez sur Submit.
   
   
5. Cliquez sur le bouton de modifications de validation. Vous pouvez ajouter un commentaire facultatif à ce moment, si désiré.
   
   
6. Modifications de validation de clic afin de sauvegarder les modifications.

La stratégie de flux de courrier pour le groupe d'expéditeur est maintenant mise à jour avec les configurations de TLS que vous avez choisies.

Conseil : Référez-vous à l'article suivant pour plus d'informations sur la façon dont l'ESA manipule la vérification de TLS : Quel est l'algorithme pour la vérification de certificat sur l'ESA ?

Lancez le TLS sortant

Afin de lancer le TLS pour des sessions sortantes, connectez au GUI de Web, choisissez les stratégies de messagerie > les contrôles de destination, et puis terminez-vous ces étapes :

1. Cliquez sur Add la destination….
   
   
2. Ajoutez le domaine de destination (tel que domain.com).
   
   
3. Dans la section de support de TLS, cliquez sur le menu déroulant et choisissez une de ces options afin d'activer le type de TLS qui doit être configuré :
   
   
   • Aucun – Quand cette option est choisie, le TLS n'est pas négocié pour les connexions sortantes de l'interface au MTA pour le domaine.
     
     
   • Préféré – Quand cette option est choisie, le TLS est négocié de l'interface ESA au MTA pour le domaine. Cependant, si la négociation de TLS échoue (avant la réception d'une réponse 220), la transaction de SMTP continue en clair (non chiffré). Aucune tentative n'est faite afin de vérifier si le certificat provient d'un CA de confiance. Si une erreur se produit après que la réponse 220 soit reçue, alors la transaction de SMTP ne retombe pas au texte clair.
     
     
   • Requis – Quand cette option est choisie, le TLS est négocié de l'interface ESA au MTA pour le domaine. Aucune tentative n'est faite afin de vérifier le certificat du domaine. Si la négociation échoue, aucun email n'est envoyé par la connexion. Si la négociation réussit, alors la messagerie est fournie par l'intermédiaire d'une session chiffrée.
     
     
   • Préférer-vérifiez – Quand cette option est choisie, le TLS est négocié de l'ESA au MTA pour le domaine, et des tentatives d'appareils de vérifier le certificat de domaine. Dans ce cas, ces trois résultats sont possibles :
     
     
     • Le TLS est négocié et le certificat est vérifié. La messagerie est fournie par l'intermédiaire d'une session chiffrée.
       
       
     • Le TLS est négocié, mais le certificat n'est pas vérifié. La messagerie est fournie par l'intermédiaire d'une session chiffrée.
       
       
     • Aucun rapport de TLS n'est établi, et le certificat n'est pas vérifié. Le message électronique est fourni en texte brut.
   • Exiger-vérifiez – Quand cette option est choisie, le TLS est négocié de l'ESA au MTA pour le domaine, et la vérification du certificat de domaine est exigée. Dans ce cas, ces trois résultats sont possibles :
     
     
     • Une connexion de TLS est négociée, et le certificat est vérifié. Le message électronique est fourni par l'intermédiaire d'une session chiffrée.
       
       
     • Une connexion de TLS est négociée, mais le certificat n'est pas vérifié par un CA de confiance. La messagerie n'est pas fournie.
       
       
     • Une connexion de TLS n'est pas négociée, mais la messagerie n'est pas fournie.
4. Apportez pas plus les modifications qui sont nécessaires les contrôles de destination pour le domaine de destination.
   
   
5. Cliquez sur Submit.
   
   
6. Cliquez sur le bouton de modifications de validation. Vous pouvez ajouter un commentaire facultatif à ce moment, si désiré.
   
   
7. Modifications de validation de clic afin de sauvegarder les modifications.

Symptômes de mauvaise configuration de certificat ESA

Le TLS fonctionnera avec un certificat auto-signé, cependant si la vérification de TLS est exigée par l'expéditeur, un certificat signé CA devrait être installé.

La vérification de TLS peut échouer quoiqu'un certificat signé CA ait été installé sur l'ESA.

Dans des ces cas, il est recommandé pour vérifier le certicate par l'intermédiaire des étapes dans la section de vérifier.

Vérifiez

Vérifiez le TLS avec un navigateur Web

Afin de vérifier le certificat signé CA, appliquez le certificat au service GUI HTTPS ESA.

Puis, naviguez vers le GUI de votre ESA en votre navigateur Web. S'il y a des avertissements quand vous naviguez vers https://youresa, alors le certificat est incorrectement enchaîné probable, comme manquer un certificat intermédiaire.

Vérifiez le TLS avec des outils tiers

Avant le test, assurez que le certificat à tester est appliqué à l'auditeur où votre appliance reçoit la messagerie d'arrivée.

Des outils tiers tels que CheckTLS.com et le SSL-Tools.net peuvent être utilisés pour vérifier l'enchaînement approprié du certificat.

L'exemple de la sortie de CheckTLS.com pour Tls-vérifient le succès

L'exemple de la sortie de CheckTLS.com pour Tls-vérifient la panne

• Nom commun de certificat.
  
  
• Adresse Internet (à GUI > réseau > interface).
  
  
• Adresse Internet de MX Record : c'est la colonne de serveur MX dans la table de TestReceiver.
  
  

Si un certificat signé CA était installé et vous voyez des erreurs, continuez à la section suivante pour information sur la façon dont dépanner la question.

Dépanner

Cette section décrit comment dépanner les questions de base de TLS sur l'ESA.

Certificats intermédiaires

Vous devriez rechercher les Certificats intermédiaires en double, particulièrement quand les certificats valables sont mis à jour au lieu d'une nouvelle création de certificat. Les certificats intermédiaires pourraient avoir changé, ou pourraient avoir été incorrectement enchaînés, et le certificat pourrait avoir téléchargé de plusieurs Certificats intermédiaires. Ceci peut introduire des questions d'enchaînement et de vérification de certificat.

Notifications d'enable pour des pannes requises de connexion de TLS

Vous pouvez configurer l'ESA afin d'envoyer une alerte si la négociation de TLS échoue quand des messages sont fournis à un domaine qui exige une connexion de TLS. Le message d'alerte contient le nom du domaine de destination pour la négociation défectueuse de TLS. L'ESA envoie le message d'alerte à tous les destinataires qui sont placés pour recevoir des alertes d'avertissement de niveau d'importance pour des types d'alerte système.

Remarque: C'est un paramètre général, ainsi il ne peut pas être placé sur une base de par-domaine.

Terminez-vous ces étapes afin d'activer des alertes de connexion de TLS :

1. Naviguez pour envoyer par mail des stratégies > des contrôles de destination.
   
   
2. Cliquez sur Edit les paramètres généraux.
   
   
3. Cochez l'envoi une alerte quand une connexion exigée de TLS échoue case.

Conseil : Vous pouvez également configurer cette configuration avec le destconfig > commande installée CLI.

L'ESA se connecte également les exemples pour lesquels le TLS est exigé pour un domaine, mais ne pourrait pas être utilisé dans les logs de messagerie d'appareils. Ceci se produit quand l'un de ces conditions sont remplies :

• Le distant MTA ne prend en charge pas ESMTP (par exemple, il n'a pas compris la commande EHLO de l'ESA).
  
  
• Le distant MTA prend en charge ESMTP, mais la commande STARTTLS n'était pas dans la liste d'extensions qu'elle a annoncées dans sa réponse EHLO.
  
  
• Le distant MTA a annoncé l'extension STARTTLS, mais a répondu avec une erreur quand l'ESA a envoyé la commande STARTTLS.

Localisez les sessions de communication réussies de TLS dans les logs de messagerie

Les connexions de TLS sont enregistrées dans les logs de messagerie, avec d'autres actions significatives qui sont liées aux messages, tels que les actions de filtre, l'antivirus et les verdicts d'anti-Spam, et tentatives de la livraison. S'il y a une connexion réussie de TLS, il y aura une entrée de succès de TLS dans les logs de messagerie. De même, le TLS défectueux que la connexion produit TLS a manqué entrée. Si un message n'a pas une entrée associée de TLS dans le fichier journal, ce message n'a pas été fourni au-dessus d'une connexion de TLS.

Conseil : Afin de comprendre les logs de messagerie, référez-vous au document Cisco de détermination de disposition de message ESA.

Voici un exemple d'une connexion réussie de TLS du serveur distant (réception) :

Tue Apr 17 00:57:53 2018 Info: New SMTP ICID 590125205 interface Data 1 (192.168.1.1) address 100.0.0.1 reverse dns host mail.example.com verified yes
Tue Apr 17 00:57:53 2018 Info: ICID 590125205 ACCEPT SG SUSPECTLIST match sbrs[-1.4:2.0] SBRS -1.1
Tue Apr 17 00:57:54 2018 Info: ICID 590125205 TLS success protocol TLSv1 cipher DHE-RSA-AES256-SHA
Tue Apr 17 00:57:55 2018 Info: Start MID 179701980 ICID 590125205

Voici un exemple d'une connexion défectueuse de TLS du serveur distant (réception) :

Mon Apr 16 18:59:13 2018 Info: New SMTP ICID 590052584 interface Data 1 (192.168.1.1) address 100.0.0.1 reverse dns host mail.example.com verified yes
Mon Apr 16 18:59:13 2018 Info: ICID 590052584 ACCEPT SG UNKNOWNLIST match sbrs[2.1:10.0] SBRS 2.7
Mon Apr 16 18:59:14 2018 Info: ICID 590052584 TLS failed: (336109761, 'error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher')
Mon Apr 16 18:59:14 2018 Info: ICID 590052584 lost
Mon Apr 16 18:59:14 2018 Info: ICID 590052584 close

Voici un exemple d'une connexion réussie de TLS au serveur distant (la livraison) :

Tue Apr 17 00:58:02 2018 Info: New SMTP DCID 41014367 interface 192.168.1.1 address 100.0.0.1 port 25
Tue Apr 17 00:58:02 2018 Info: DCID 41014367 TLS success protocol TLSv1.2 cipher ECDHE-RSA-AES256-GCM-SHA384 
Tue Apr 17 00:58:03 2018 Info: Delivery start DCID 41014367 MID 179701982 to RID [0]

Voici un exemple d'une connexion défectueuse de TLS au serveur distant (la livraison) :

Mon Apr 16 00:01:34 2018 Info: New SMTP DCID 40986669 interface 192.168.1.1 address 100.0.0.1 port 25
Mon Apr 16 00:01:35 2018 Info: Connection Error: DCID 40986669 domain: domain.com IP:100.0.0.1 port: 25 details: 454-'TLS not available due to
 temporary reason' interface: 192.168.1.1 reason: unexpected SMTP response
Mon Apr 16 00:01:35 2018 Info: DCID 40986669 TLS failed: STARTTLS unexpected response

Informations connexes

• Appliance de sécurité du courrier électronique de Cisco - Guides d'utilisateur
• Appliance de Gestion de sécurité du contenu de Cisco - Guides d'utilisateur
• Support et documentation techniques - Cisco Systems