Avez-vous un compte?
Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.
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).
Aucune spécification déterminée n'est requise pour ce document.
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.
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.
Un administrateur pourrait désirer créer un certificat auto-signé sur l'appliance pour l'un de ces raisons :
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.
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.
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.
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.
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 :
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à.
Terminez-vous ces étapes afin de soumettre le certificat auto-signé à un CA pour la signature :
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.
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 :
Conseil : Vous pouvez employer la boîte à outils d'OpenSSL, un programme de logiciel gratuit, afin de convertir le format.
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é.
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.
Terminez-vous ces étapes afin d'utiliser le certificat pour les services d'arrivée de TLS :
Terminez-vous ces étapes afin d'utiliser le certificat pour les services sortants de TLS :
Terminez-vous ces étapes afin d'utiliser le certificat pour les services HTTPS :
Terminez-vous ces étapes afin d'utiliser le certificat pour les LDAP :
Terminez-vous ces étapes afin d'utiliser le certificat pour le Filtrage URL :
Do you want to set client certificate for Cisco Web Security Services Authentication?
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 :
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.
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 :
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 :
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 ?
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 :
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.
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.
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
Remarque: Si un certifcate auto-signé est en service, le résultat prévu dans la colonne CORRECTE de « CERT » est « ÉCHOUER ».
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.
Cette section décrit comment dépanner les questions de base de TLS sur l'ESA.
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.
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 :
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 :
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