Utilisation de la la sécurité de domaine : configuration de Mutual TLS
S’applique à : Exchange Server 2010 SP2, Exchange Server 2010 SP3
Dernière rubrique modifiée : 2009-12-07
Cette rubrique explique comment configurer le protocole TLS (Transport Layer Security) mutuel pour la sécurité du domaine, l’ensemble des fonctionnalités dans Microsoft Exchange Server 2010 et Microsoft Office Outlook 2007 qui fournissent une alternative moins coûteuse S/MIME et d’autres solutions de sécurité au niveau message.
Dans le cadre de ce scénario, cette rubrique explique comment des administrateurs Exchange d’une société fictive, Contoso, configurent l’environnement Exchange 2010 pour échanger des messages électroniques de domaines sécurisés avec leur partenaire, Woodgrove Bank. Les administrateurs Contoso veulent s’assurer que tout message électronique échangé avec Woodgrove Bank est protégé par le TLS mutuel. En outre, ils veulent configurer les fonctionnalités de la sécurité du domaine afin que tous les messages échangés avec Woodgrove Bank soient rejetés si le TLS mutuel ne peut pas être utilisé.
Contoso dispose d’une infrastructure à clé publique interne (PKI) qui génère des certificats. Le certificat racine de la PKI a été signé par une autorité de certification tierce de premier plan. Woodgrove Bank utilise la même autorité de certification pour générer ses certificats. Ainsi, Contoso et Woodgrove Bank font mutuellement confiance à l’autorité de certification racine de l’autre.
Pour configurer le TLS mutuel, les administrateurs Exchange de Contoso exécutent les procédures ci-après :
Étape 1 : Générer une demande de certificat pour des certificats TLS
Étape 2 : Importer des certificats sur des serveurs de transport Edge
Étape 3 : Configurer la sécurité du domaine sortant
Étape 4 : Configurer la sécurité du domaine entrant
Étape 5 : Test du flux de messagerie de domaine sécurisé
Conditions préalables
Cette rubrique suppose que vous avez lu et compris la rubrique Générer une demande pour les services de certificat de tiers.
Le service Microsoft Exchange EdgeSync doit être entièrement déployé pour la sécurité du domaine. En général, les changements de configuration apportés à la fonctionnalité de sécurité du domaine n’utilisant pas les cmdlets ExchangeCertificate doivent être effectués au sein de l’organisation et synchronisés sur des serveurs de transport Edge en utilisant le service Microsoft Exchange EdgeSync.
Avant de pouvoir exécuter avec succès le TLS mutuel sur un serveur de transport Edge, vous devez configurer l’ordinateur et l’environnement ICP pour que la validation du certificat et le contrôle de la liste de révocation des certificats soient opérationnels. Pour plus d’informations, consultez la rubrique Utilisation d'une infrastructure à clé publique sur le serveur de transport Edge pour la sécurité d'un domaine.
Même si des étapes de configuration individuelles avec ce scénario peuvent être effectuées avec moins de droits pour effectuer les scénarios dans leur intégralité de bout en bout, votre compte doit être un membre d’un groupe de rôles de gestion Gestion de l’organisation.
Étape 1 : Générer une demande de certificat pour des certificats TLS
Contoso dispose d’une infrastructure à clé publique interne qui est dépendante d’une autorité de certification tierce. Dans ce cas, la subordination désigne le fait que l’autorité de certification déployée par Contoso dans son infrastructure contienne un certificat racine signé par une autorité de certification publique tierce. L’autorité de certification publique tierce est, par défaut, l’un des certificats racines approuvés de la banque de certificats Microsoft Windows. Par conséquent, chaque client qui insère cette autorité de certification tierce dans sa banque racine approuvée et qui se connecte à Contoso peut s’authentifier par rapport au certificat présenté par Contoso.
Contoso dispose de deux serveurs de transport Edge nécessitant des certificats TLS : mail1.contoso.com et mail2.mail.contoso.com. Ainsi, l’administrateur de courrier électronique Contoso doit générer deux demandes de certificat, une pour chaque serveur.
L’exemple suivant indique la commande que l’administrateur doit utiliser pour générer des demandes de certificat codées en base 64 PKCS#10.
L’administrateur de Contoso doit exécuter cette commande pour CN=mail1.contoso.com.
$Data1 = New-ExchangeCertificate -GenerateRequest -FriendlyName "Internet certificate for mail1" -SubjectName "DC=com,DC=Contoso,CN=mail1.contoso.com" -DomainName mail.contoso.com
Set-Content -Path "C:\Certificates\mail1-request.req" -Value $Data1
L’administrateur de Contoso doit exécuter cette commande pour CN=mail2.mail.contoso.com.
$Data2 = New-ExchangeCertificate -GenerateRequest -FriendlyName "Internet certificate for mail2" -SubjectName "DC=com,DC=Contoso,CN=mail2.mail.contoso.com" -DomainName mail.contoso.com
Set-Content -Path "C:\Certificates\mail2-request.req" -Value $Data2
Pour obtenir des informations détaillées sur la syntaxe et les paramètres, consultez la rubrique New-ExchangeCertificate.
Important : |
---|
Les détails spécifiques du certificat ou de la demande de certificat que vous créez dépendent de nombreuses variables. Si vous générez une demande, veillez à collaborer étroitement avec l’autorité de certification ou l’administrateur d’infrastructure à clé publique émettant le certificat. Pour plus d’informations sur la création d’une demande de certificat pour le protocole TLS, voir Générer une demande pour les services de certificat de tiers. |
Retour au début
Étape 2 : Importer des certificats sur des serveurs de transport Edge
Après que l’administrateur Contoso a généré les demandes de certificats, l’administrateur de l’autorité de certification pour Contoso utilise les demandes pour générer les certificats pour les serveurs. Les certificats résultants doivent être délivrés soient comme certificats uniques ou comme chaîne de certificats et copiés sur les serveurs de transport Edge appropriés.
Important : |
---|
Il est déconseillé d’utiliser le composant logiciel enfichable Gestionnaire de certificats de MMC (Microsoft Management Console) pour importer les certificats pour le protocole TLS sur le serveur Exchange. L’utilisation du composant logiciel enfichable Gestionnaire de certificats pour l’importation de certificats sur des serveurs Exchange ne lie pas la demande créée dans cette procédure au certificat délivré. Par conséquent, le protocole TLS risque d’échouer. Vous pouvez utiliser le composant logiciel enfichable Gestionnaire de certificats pour importer des certificats et des clés stockés sous la forme de fichiers .pfx dans le magasin de l’ordinateur local. |
Lorsque vous importez le certificat sur le serveur de transport Edge, vous devez également activer le certificat pour le service SMTP. L’administrateur de Contoso exécute la commande suivante sur chaque serveur de transport Edge, une fois pour chaque certificat respectif.
Import-ExchangeCertificate -FileData ([Byte[]]$(Get-Content -Path C:\Certificates\mail1-certificate.pfx -Encoding Byte -ReadCount 0)) | Enable-ExchangeCertificate -Services SMTP
L’exemple précédent importe et active le certificat TLS en canalisant le certificat pour la cmdlet Enable-ExchangeCertificate. Vous pouvez également activer le certificat après l’avoir importé. Si vous procédez ainsi, vous devrez spécifier l’empreinte du certificat que vous souhaitez activer.
Pour obtenir des informations détaillées sur la syntaxe et les paramètres, consultez les rubriques Import-ExchangeCertificate et Enable-ExchangeCertificate :
Transport de certificats et de clés connexes
Lorsque vous recevez un certificat de votre fournisseur d’infrastructure à clé publique ou d’autorité de certification, convertissez-le en fichier .pfx (PKCS#12) de façon à pouvoir le sauvegarder dans le cadre d’un plan de récupération d’urgence. Un fichier .pfx contient le certificat et les clés connexes. Dans certains cas, vous pouvez transporter le certificat et les clés pour les déplacer vers d’autres ordinateurs. Par exemple, si vous avez plusieurs serveurs de transport Edge à l’aide desquels vous projetez d’envoyer et de recevoir des messages de domaine sécurisé, vous pouvez créer un certificat unique qui fonctionne avec tous les serveurs. Dans ce cas, le certificat doit être importé et activé pour le protocole TLS sur chaque serveur de transport Edge.
Tant que vous conservez une copie du fichier .pfx soigneusement archivée, vous pouvez importer et activer le certificat. Comme le fichier .pfx contient la clé privée, il est important de le protéger physiquement en le conservant sur un support de stockage rangé en lieu sûr.
Il est important de comprendre que la cmdlet Import-ExchangeCertificate marque toujours la clé privée importée à partir du fichier .pfx comme non exportable. Cette fonctionnalité découle de la conception de l’application.
Si vous utilisez le composant logiciel enfichable Gestionnaire de certificats de la console de gestion Microsoft pour importer un fichier .pfx, vous pouvez spécifier l’exportabilité de la clé privée et une protection élevée par clé.
Important : |
---|
N’activez pas de protection élevée par clé sur des certificats destinés au protocole TLS. Une protection élevée par clé affiche une invite pour l’utilisateur à chaque accès à la clé privée. En ce qui concerne la sécurité du domaine, l’« utilisateur » est le service SMTP sur le serveur de transport Edge. |
Retour au début
Étape 3 : Configurer la sécurité du domaine sortant
Vous devez exécuter trois étapes pour configurer la sécurité du domaine sortant :
Exécutez la cmdlet Set-TransportConfig pour spécifier le domaine avec lequel vous souhaitez envoyer le courrier électronique de domaine sécurisé.
Exécutez la cmdlet Set-SendConnector pour définir la propriété DomainSecureEnabled sur le connecteur d’envoi qui doit envoyer le courrier au domaine avec lequel vous souhaitez envoyer le courrier électronique de domaine sécurisé.
Exécutez la cmdlet Get-SendConnector pour vérifier les éléments suivants :
Le connecteur d’envoi qui envoie le courrier électronique au domaine avec lequel vous souhaitez envoyer le courrier électronique de domaine sécurisé route le courrier avec le système DNS (Domain Name System).
Le FQDN est défini pour faire correspondre le nom de l’objet ou l’autre nom de l’objet de certificats que vous utilisez pour la sécurité du domaine.
Les changements que vous effectuez dans ces trois étapes étant globaux, vous devez effectuer les changements sur un serveur interne Exchange. Les changements de configuration que vous effectuez seront répliqués vers les serveurs de transport Edge via le service Microsoft Exchange EdgeSync.
Étape 3a : Spécifier le domaine expéditeur dans la configuration de transport
Il est relativement simple de spécifier le domaine avec lequel vous souhaitez envoyer le message électronique de domaine sécurisé. L’administrateur de Contoso exécute la commande suivante sur un serveur interne Exchange 2010.
Set-TransportConfig -TLSSendDomainSecureList woodgrovebank.com
Le paramètre TLSSendDomainSecureList prend une liste de plusieurs valeurs de noms de domaine. La commande Set-TransportConfig remplace la valeur entière pour TLSSendDomainSecureList par la nouvelle valeur fournie dans la cmdlet. Par conséquent, si vous disposez d’autres domaines déjà configurés et que vous souhaitez ajouter un domaine, vous devez inclure le domaine existant dans la liste ou utiliser une variable temporaire. L’exemple suivant montre comment ajouter le domaine woodgrovebank.com au paramètre TLSSendDomainSecureList sans écraser les valeurs existantes.
$TransportConfig = Get-TransportConfig
$TransportConfig.TLSSendDomainSecureList += "woodgrovebank.com"
Set-TransportConfig -TLSSendDomainSecureList $TransportConfig.TLSSendDomainSecureList
Pour obtenir des informations détaillées sur la syntaxe et les paramètres, voir Set-TransportConfig.
Étape 3 b : Configurer le connecteur d’envoi par défaut
Contoso utilise leur connecteur d’envoi acheminé par DNS par défaut nommé Internet pour envoyer les courriers électroniques de domaines sécurisés à leur partenaire. Étant donné que leur connecteur d’envoi acheminé par DNS par défaut est un connecteur d’envoi Internet par défaut, il utilise le DNS pour acheminer les courriers et n’utilise aucun hôte actif. Le FQDN est déjà défini sur mail.contoso.com
. Puisque les certificats que l’administrateur Contoso a créés définissent le paramètre DomainName de New-ExchangeCertificate sur mail.contoso.com
, le connecteur d’envoi peut utiliser les certificats sans configuration supplémentaire.
Si vous avez configuré un sous-domaine à des fins de test, il se peut que vous deviez mettre à jour le nom de domaine complet de votre Connecteur d’envoi afin qu’il corresponde au certificat que vous avez créé (par exemple, sousdomaine.courrier.contoso.com). En revanche, si vous avez créé un certificat contenant le sous-domaine dans les champs Objet ou Autre nom de l’objet, vous n’avez pas besoin de mettre à jour le nom de domaine complet du connecteur d’envoi.
Par conséquent, la seule configuration que l’administrateur contoso doit effectuer vers le connecteur d’envoi est de définir le paramètre DomainSecureEnabled. Pour ce faire, l’administrateur contoso exécute la commande suivante sur un serveur interne Exchange 2010 pour le connecteur d’envoi « Internet ».
Set-SendConnector Internet -DomainSecureEnabled:$true
Pour obtenir des informations détaillées sur la syntaxe et les paramètres, voir Set-SendConnector.
Étape 3 c : Vérifier la configuration de connecteur d’envoi
Après avoir terminé les modifications de configuration, l’administrateur Contoso doit vérifier que le connecteur d’envoi en cours d’utilisation pour la sécurité du domaine est configuré correctement. Pour ce faire, l’administrateur Contoso doit exécuter la commande suivante.
Get-SendConnector Internet | Format-List Name,DNSRoutingEnabled,FQDN,DomainSecureEnabled
Cette commande répertorie les paramètres pertinents configurés pour la sécurité du domaine, en autorisant l’administrateur Contoso à vérifier la configuration.
Pour obtenir des informations détaillées sur la syntaxe et les paramètres, voir Get-SendConnector.
Retour au début
Étape 4 : Configurer la sécurité du domaine entrant
Vous devez exécuter deux étapes pour configurer la sécurité du domaine entrant :
Exécutez la cmdlet Set-TransportConfig pour spécifier le domaine à partir duquel vous souhaitez recevoir le courrier électronique de domaine sécurisé.
Sur le serveur de transport Edge, utilisez l’environnement de ligne de commande Exchange Management Shell ou la console de gestion Exchange pour activer la sécurité du domaine sur le connecteur de réception à partir duquel vous souhaitez recevoir les messages électroniques de domaine sécurisé. Étant donné que la Sécurité du domaine nécessite l’authentification mutuelle TLS, TLS devrait également être activé sur le connecteur de réception.
Étape 4 a : Spécifier le domaine de destinataire dans la configuration de transport
Il est relativement simple de spécifier le domaine avec lequel vous souhaitez recevoir le message électronique de domaine sécurisé. Pour spécifier le domaine, l’administrateur de Contoso exécute la commande suivante dans l’environnement de ligne de commande Exchange Management Shell sur un serveur interne Exchange 2010 ou une station de gestion.
Set-TransportConfig -TLSReceiveDomainSecureList woodgrovebank.com
Le paramètre TLSReceiveDomainSecureList prend une liste de plusieurs valeurs de noms de domaine. La commande Set-TransportConfig remplace la valeur entière pour le paramètre TLSReceiveDomainSecureList avec la nouvelle valeur fournie par la cmdlet Set-TransportConfig. Par conséquent, si vous disposez d’autres domaines déjà configurés et que vous souhaitez ajouter un domaine, vous devez inclure le domaine existant dans la liste ou utiliser une variable temporaire. L’exemple suivant montre comment ajouter le domaine woodgrovebank.com au paramètre TLSReceiveDomainSecureList sans écraser les valeurs existantes.
$TransportConfig = Get-TransportConfig
$TransportConfig.TLSReceiveDomainSecureList += "woodgrovebank.com"
Set-TransportConfig -TLSReceiveDomainSecureList $TransportConfig.TLSReceiveDomainSecureList
Pour obtenir des informations détaillées sur la syntaxe et les paramètres, voir Set-TransportConfig.
Étape 4 b : Configurer le connecteur de réception
Vous devez configurez le connecteur de réception sur chaque serveur de transport Edge acceptant les courriers des domaines à partir desquels vous souhaiteriez recevoir les courriers électroniques de domaine sécurisé. L’environnement Contoso est configuré pour avoir un connecteur de réception Internet unique, avec une valeur de paramètre Identity d’Internet sur chacun des serveurs de transport Edge. Ainsi, pour activer TLS pendant que le courrier est envoyé ou reçu à partir de la Woodgrove Bank, l’administrateur de Contoso devrait s’assurer que TLS est activé sur le connecteur de réception Internet par défaut des deux serveurs de transport Edge. Pour ce faire, l’administrateur de Contoso exécute la commande suivante sur mail1.contoso.com et mail2.mail.contoso.com.
Set-ReceiveConnector Internet -DomainSecureEnabled $true -AuthMechanism TLS
Pour obtenir des informations détaillées sur la syntaxe et les paramètres, consultez la rubrique Set-ReceiveConnector.
Vous pouvez également utiliser la console de gestion Exchange pour configurer le connecteur de réception en utilisant les étapes suivantes.
Sur le serveur de transport Edge, ouvrez la console de gestion Exchange, cliquez sur Transport Edge, puis dans le volet Résultats, cliquez sur l’onglet Connecteur de réception.
Sélectionnez le connecteur de réception qui accepte les courriers du domaine à partir duquel vous souhaitez recevoir le courrier électronique de domaine sécurisé. Puis, dans le volet action, cliquez sur Propriétés.
Sur l’onglet, Authentification, sélectionnez Protocole TLS (Transport Layer Security) et Sécurité du domaine activée (Authentification mutuelle TLS) , puis, cliquez sur OK.
Sachez que la spécification du mécanisme d’authentification comme TLS n’impose pas le protocole TLS sur toutes les connexions entrantes.
Le protocole TLS est obligatoire pour les connexions en provenance de la Woodgrove Bank pour les raisons suivantes :
Woodgrove Bank est spécifié dans la cmdlet Set-TransportConfig sur le paramètre TLSReceiveDomainSecureList.
Le paramètre DomainSecureEnabled est défini à
$true
sur le connecteur de réception.
Les autres expéditeurs non énumérés sur le paramètre TLSReceiveDomainSecureList dans la cmdlet Set-TransportConfig utilisent TLS uniquement s’il est pris en charge par le système d’envoi.
Retour au début
Étape 5 : Test du flux de messagerie de domaine sécurisé
Après avoir configuré le courrier électronique de domaine sécurisé, vous pouvez tester la connexion en analysant les journaux de performance et les journaux de protocole. Les messages qui ont été authentifiés avec succès sur le chemin de flux de messagerie de domaine sécurisé sont affichés dans Outlook comme messages de « domaine sécurisé ».
Compteurs de performance
La fonctionnalité de sécurité du domaine inclus l’ensemble des compteurs de performance suivants sous MSExchange Secure Mail Transport :
Messages de domaine sécurisé reçus
Messages de domaine sécurisé envoyés
Échecs de session sortante de domaine sécurisé
Vous pouvez créer un nouveau fichier de journal de compteurs pour le flux de messagerie de domaine sécurisé. Ces compteurs de performance analysent le nombre de messages envoyés et reçus ainsi que les sessions TLS mutuelles qui ont échouées. Pour plus d’informations sur la création et la configuration des journaux de compteurs, voir le fichier d’Aide inclus dans le composant logiciel enfichable MMC Journaux et alertes de performance.
Journaux de protocole
Vous pouvez analyser les journaux de protocole d’envoi et de réception pour déterminer si la négociation TLS s’est déroulée avec succès.
Pour afficher des journaux de protocole détaillés, vous devez définir le niveau d’enregistrement dans le journal sur Verbose
sur les connecteurs que votre organisation utilise pour envoyer et recevoir du courrier électronique de domaine sécurisé. Pour ce faire, l’administrateur de Contoso exécute ce qui suit sur les serveurs de transport Edge.
Set-ReceiveConnector Internet -ProtocolLoggingLevel Verbose
Pour activer le journal de protocole sur le connecteur d’envoi, l’administrateur de Contoso exécute ce qui suit sur un serveur Exchange interne ou une station de travail de gestion. La modification de configuration est ensuite répliquée sur les serveurs de transport Edge à l’aide du service Microsoft Exchange EdgeSync.
Set-SendConnector Internet -ProtocolLoggingLevel Verbose
Pour obtenir des informations détaillées sur la syntaxe et les paramètres, consultez les rubriques Set-ReceiveConnector et Set-SendConnector :
Pour plus d’informations sur l’affichage de journaux de protocole, consultez la rubrique Configurer l’enregistrement dans le journal de protocole.
Retour au début
© 2010 Microsoft Corporation. Tous droits réservés.