Procédure de configuration de Mutual TLS pour la sécurité d'un domaine
S’applique à : Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007
Dernière rubrique modifiée : 2009-04-20
Cette rubrique explique comment utiliser l'environnement de ligne de commande Exchange Management Shell pour configurer le protocole TLS (Transport Layer Security) mutuel pour la sécurité du domaine, à savoir l’ensemble des fonctionnalités dans Microsoft Exchange Server 2007 et Microsoft Office Outlook 2007 qui fournissent une alternative moins coûteuse S/MIME et d’autres solutions de sécurité au niveau message.
À titre illustratif, cette rubrique explique comment des administrateurs Exchange d’une société fictive, Contoso, configurent l'environnement Exchange 2007 pour échanger des messages électroniques de domaines sécurisés avec leur partenaire, Woodgrove Bank. Dans le cadre de ce scénario, Contoso veut s’assurer que tout message électronique échangé avec Woodgrove Bank est protégé par le TLS mutuel. En outre, Contoso veut 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 :
génération d’une demande de certificat pour les certificats TLS ;
importation du certificat sur les serveurs de transport Edge ;
Configuration de la sécurité de domaine sortant.
configuration de la sécurité de domaine entrant ;
test du flux de messagerie.
Avant de commencer
La configuration du TLS mutuel requiert les éléments suivants :
Accédez aux serveurs Exchange 2007 internes à l'aide des cmdlets Set-TransportConfig et New-SendConnector si vous n'avez pas configuré de connecteurs d'envoi.
Accédez aux ordinateurs de serveur de transport Edge exécutant les cmdlets ExchangeCertificate.
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 EdgeSync Microsoft Exchange.
Lorsque vous importez et configurez les certificats TLS à l'aide des cmdlets ExchangeCertificate, vous devez exécuter ces dernières sur le serveur de transport Edge que vous configurez. Pour exécuter la cmdlet Remove-ExchangeCertificate sur un ordinateur sur lequel le rôle serveur de transport Edge est installé, vous devez ouvrir une session en utilisant un compte membre du groupe Administrateurs local sur cet ordinateur.
Pour exécuter la cmdlet Set-TransportConfig, vous devez utiliser un compte auquel le rôle Administrateur des destinataires Exchange a été délégué.
Pour exécuter la cmdlet New-SendConnector, vous devez utiliser un compte auquel le rôle Administrateur de serveur Exchange et le groupe Administrateurs local ont été délégués.
Pour plus d'informations sur les autorisations, la délégation de rôles et les droits requis pour administrer Exchange 2007, consultez la rubrique Considérations relatives aux autorisations.
Cette rubrique suppose que vous avez lu et compris la rubrique Création d’un certificat ou demande de certificat pour TLS.
Le service Microsoft Exchange EdgeSync doit être entièrement déployé pour la sécurité du domaine.
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 Procédure d'activation d'une infrastructure à clé publique sur le serveur de transport Edge pour la sécurité d'un domaine.
Génération d’une demande de certificat pour des certificats TLS
Comme indiqué précédemment dans cette rubrique, Contoso dispose d’une PKI interne subordonnée à 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.
La procédure suivante indique la commande que l’administrateur doit utiliser pour générer une demande de certificat de type base64-encoded PKCS#10. L’administrateur de Contoso doit exécuter cette commande deux fois : Une fois pour CN=mail1.contoso.com et une fois pour CN=mail2.mail.contoso.com.
Notes
Les noms communs (CN) de Nom du sujet des certificats obtenus sont respectivement mail1.contoso.com et mail2.mail.contoso.com. L'Autre nom de l'objet contient « mail.contoso.com », qui est le nom de domaine complet (FQDN) de l’un des domaines acceptés configurés pour Contoso.
Création d'une demande de certificat TLS
Exécutez la commande suivante :
New-ExchangeCertificate -GenerateRequest -FriendlyName "Internet certificate" -Path c:\certificates\request.p7c -SubjectName "DC=com,DC=Contoso,CN=mail1.contoso.com" -DomainName mail.contoso.com
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, consultez la rubrique Création d’un certificat ou demande de certificat pour TLS. |
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 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 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 (MMC) 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. |
Importation de certificats sur des serveurs de transport Edge
Après avoir généré les demandes de certificats, l'administrateur les utilise 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 : |
---|
Pour importer les certificats, vous devez utiliser la cmdlet Import-ExchangeCertificate. Pour plus d'informations, consultez la rubrique Import-ExchangeCertificate. |
Important : |
---|
Il est déconseillé d’utiliser le composant logiciel enfichable Gestionnaire de certificats de MMC 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. Une fois les certificats importés, vous pouvez activer le certificat pour le protocole TLS en exécutant la cmdlet Enable-ExchangeCertificate. |
Lorsque vous importez le certificat sur le serveur de transport Edge, vous devez également activer le certificat pour le protocole SMTP (Simple Mail Transfer Protocol). L’administrateur de Contoso exécute la commande suivante sur chaque serveur de transport Edge, une fois pour chaque certificat respectif.
Importation et activation d’un certificat TLS pour la sécurité du domaine sur un serveur de transport Edge
Exécutez la commande suivante :
Import-ExchangeCertificate -Path c:\certificates\import.pfx | Enable-ExchangeCertificate -Services SMTP
Cette commande importe et active le certificat TLS en canalisant la cmdlet Enable-ExchangeCertificate.
Vous pouvez également activer le certificat après l’avoir importé. Pour importer le certificat, exécutez la commande suivante :
Import-ExchangeCertificate -Path c:\certificates\import.pfx
Ensuite, copiez l'empreinte dans le Presse-papiers Windows. Pour afficher l'empreinte du certificat que vous venez d'importer, exécutez la commande suivante :
Get-ExchangeCertificate |FL
Copiez les données du champ Empreinte dans le Presse-papiers Windows.
Enfin, pour activer le certificat, exécutez la commande suivante :
Enable-ExchangeCertificate -Thumbprint AB493A0C9A6C0327162FE04EF74609CB8FB7FE24 -Services SMTP
Configuration de la sécurité du domaine sortant
Vous devez exécutez 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 Set-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 soit le Nom de rubrique ou le Nom alternatif de rubrique 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.
Spécification du 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 2007 :
Set-TransportConfig -TLSSendDomainSecureList woodgrovebank.com
Pour plus d'informations, consultez la rubrique Set-TransportConfig.
Notes
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. Ainsi, si vous souhaitez ajoutez un nouveau domaine, la valeur que vous fournissez doit inclure la liste existante et le nouveau domaine.
Configuration d'un connecteur d'envoi
Contoso utilise leur connecteur d’envoi acheminé par DNS par défaut 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 ne devez pas 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 le faire, l’administrateur contoso exécute la commande suivante sur un serveur interne Exchange 2007 pour le connecteur d’envoi « Internet ».
Set-SendConnector Internet -DomainSecureEnabled:$True
Pour plus d'informations, consultez la rubrique Set-SendConnector.
Vous pouvez également utiliser la console de gestion Exchange pour activer le message électronique de domaine sécurisé sur un connecteur d’envoi.
Utilisation de la console de gestion Exchange pour configurer un connecteur d'envoi pour la sécurité de domaine
Sur un serveur de transport Hub, ouvrez la console de gestion Exchange, cliquez sur Configuration de l’organisation, cliquez sur Transport Hub, puis, dans le volet résultats, cliquez sur l’onglet Connecteurs d’envoi.
Sélectionnez le connecteur d’envoi qui envoie les messages au domaine à partir duquel vous souhaitez envoyer le message électronique de domaine sécurisé, ensuite, dans le volet action, cliquer sur Propriétés.
Sur l’onglet Réseau, sélectionnez Sécurité du domaine activé (Mutual Auth TLS) , cliquer sur Appliquer, et cliquer ensuite sur OK.
Configuration de la sécurité du domaine entrant
Vous devez exécutez 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.
Spécification du domaine de destinataire dans la configuration de transport
Il est relativement simple de spécifier le domaine avec lequel vous souhaiteriez recevoir le courrier électronique de domaine sécurisé. Pour spécifier le domaine, l’administrateur de Contoso exécute la commande suivante sur un serveur interne Exchange 2007 :
Set-TransportConfig -TLSReceiveDomainSecureList woodgrovebank.com
Pour plus d'informations, consultez la rubrique Set-TransportConfig.
Notes
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 le cmdlet Set-TransportConfig. Ainsi, si vous souhaitez ajoutez un nouveau domaine, la valeur que vous fournissez doit inclure la liste existante et le nouveau domaine.
Configuration d'un 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 identité Inet, 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.
Utilisation de l'environnement de ligne de commande Exchange Management Shell pour configurer un connecteur de réception pour la sécurité de domaine
Sur le serveur de transport Edge, exécutez la commande suivante :
Set-ReceiveConnector Inet -DomainSecureEnabled:$True -AuthMechanism TLS
Pour obtenir des informations détaillées sur la syntaxe et les paramètres, consultez la rubrique Set-ReceiveConnector.
Utilisation de la console de gestion Exchange pour configurer un connecteur de réception pour la sécurité de domaine
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 Connecteurs 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é, ensuite, 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 à l'aide du paramètre TLSReceiveDomainSecureList.
Le paramètre DomainSecureEnabled est défini sur
$True
pour 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.
Notes
L’inconvénient de l’activation de la sécurité du domaine sur un serveur de réception est que le certificat du client est requis au cours de négociation TLS. Si le domaine à partir duquel le client envoie ne figure pas dans la liste de domaines sécurisés, la présentation du certificat par le client n’est pas obligatoire client.
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 a été authentifiés avec succès sur le chemin de flux de messagerie de domaine sécurisé sont affichés dans Outlook 2007 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, consultez 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. La négociation TLS déroulée avec succès génère des journaux similaires aux exemples suivants.
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é.
Utilisation de l'environnement de ligne de commande Exchange Management Shell pour configurer un connecteur de réception pour le niveau d'enregistrement détaillé
Sur le serveur de transport Edge, exécutez la commande suivante :
Set-ReceiveConnector Inet -ProtocolLoggingLevel Verbose
Où
Inet
est le nom du Connecteur de réception sur lequel le courrier électronique de domaine sécurisé est activé.
Utilisation de l'environnement de ligne de commande Exchange Management Shell pour configurer un connecteur d'envoi pour le niveau d'enregistrement détaillé
Sur le serveur de transport Edge, exécutez la commande suivante :
Set-SendConnector Internet -ProtocolLoggingLevel Verbose
Où
Internet
est le nom du Connecteur d'envoi sur lequel le courrier électronique de domaine sécurisé est activé.
Exemple de journal d'envoi
<220 edgedns3 ESMTP Microsoft ESMTP MAIL Service, Version: 8.0.647.0; Tue, 29 Aug 2006 04:22:00 -0700 (PDT)
>EHLO edgea36.dns.contoso.com
<250-edgedns3 Hello woodgrove.com [192.168.0.2], pleased to meet you
<250-ENHANCEDSTATUSCODES
<250-PIPELINING
<250-EXPN
<250-VERB
<250-8BITMIME
<250-SIZE
<250-DSN
<250-ETRN
<250-STARTTLS
<250-DELIVERBY
<250 HELP
>STARTTLS
<220 2.0.0 Ready to start TLS
*Sending certificate
*CN=edgea36, Certificate subject
*CN=edgea36, Certificate issuer name
*CA2EDF2487C6F09B4E413FD3812A7F89, Certificate serial number
*E8DA062786FD097DD8D79FF10C583CC23AD64F6C, Certificate thumbprint
*edgea36;edgea36.dns.contoso.com, Certificate alternate names
*Received certificate
*CN=smi.extest.contoso.com, OU=Contoso, O=Corp, L=Spokane, S=WA, C=US, Certificate subject
*CN=ExCertDom EntSub Issuing CA v1.0, DC=ExCertDom, DC=ExTest, DC=Contoso, DC=Com, Certificate issuer name
*446DD186000A00002819, Certificate serial number
*DC27B5F8657F84B15B5004BE63CE482721871582, Certificate thumbprint
*smi.extest.contoso.com, Certificate alternate names
>EHLO edgea36.dns.contoso.com
<250-edgedns3 Hello woodgrove.com [192.168.0.2], pleased to meet you
<250-ENHANCEDSTATUSCODES
<250-PIPELINING
<250-EXPN
<250-VERB
<250-8BITMIME
<250-SIZE
<250-DSN
<250-ETRN
<250-DELIVERBY
<250 HELP
*08C895F533E837EC;2006-08-28T22:37:53.323Z;1, sending message
>MAIL FROM:<user@example.com> SIZE=614
>RCPT TO:<root@smi.extest.contoso.com>
<250 2.1.0 <user@example.com>... Sender ok
<250 2.1.5 <root@smi.extest.contoso.com>... Recipient ok
>DATA
<354 Enter mail, end with "." on a line by itself
<250 2.0.0 k7TBM0BZ000043 Message accepted for delivery
>QUIT
<221 2.0.0 edgedns3 closing connection
Exemple de journal de réception
>220 edgea36 Microsoft ESMTP MAIL Service, Version: 8.0.647.0 ready at Mon, 28 Aug 2006 15:37:53 -0700
<EHLO edgedns3
>250-edgea36.dns.contoso.com Hello [192.168.0.1]
>250-SIZE 15728640
>250-PIPELINING
>250-DSN
>250-ENHANCEDSTATUSCODES
>250-STARTTLS
>250-AUTH
>250-8BITMIME
>250-BINARYMIME
>250 CHUNKING
<STARTTLS
>220 2.0.0 SMTP server ready
*Sending certificate
*CN=edgea36, Certificate subject
*CN=edgea36, Certificate issuer name
*CA2EDF2487C6F09B4E413FD3812A7F89, Certificate serial number
*E8DA062786FD097DD8D79FF10C583CC23AD64F6C, Certificate thumbprint
*edgea36;edgea36.dns.contoso.com, Certificate alternate names
*Received certificate
*CN=smi.extest.contoso.com, OU=Contoso, O=Corp, L=Spokane, S=WA, C=US, Certificate subject
*CN=ExCertDom EntSub Issuing CA v1.0, DC=ExCertDom, DC=ExTest, DC=Contoso, DC=Com, Certificate issuer name
*446DD186000A00002819, Certificate serial number
*DC27B5F8657F84B15B5004BE63CE482721871582, Certificate thumbprint
*smi.extest.contoso.com, Certificate alternate names
<EHLO edgedns3
>250-edgea36.dns.contoso.com Hello [192.168.0.1]
>250-SIZE 15728640
>250-PIPELINING
>250-DSN
>250-ENHANCEDSTATUSCODES
>250-AUTH
>250-8BITMIME
>250-BINARYMIME
>250 CHUNKING
<MAIL From:<user@smi.extest.contoso.com> SIZE=16
*08C895F533E837EC;2006-08-28T22:37:53.323Z;1, receiving message
>250 2.1.0 user@smi.extest.contoso.com Sender OK
<RCPT To:<user@woodgrove.com>
>250 2.1.5 user@woodgrove.com Recipient OK
<DATA
>354 Start mail input; end with <CRLF>.<CRLF>
>250 2.6.0 <200608281121.k7SBHYi0004586@edgedns3> Queued mail for delivery
<QUIT
>221 2.0.0 Service closing transmission channel
Pour plus d'informations sur l'affichage de journaux de protocole, consultez la rubrique Procédure de configuration de l'enregistrement dans le journal de protocole.
Pour plus d'informations sur la gestion de la sécurité du domaine dans Exchange 2007, consultez la rubrique Gestion de la sécurité d'un domaine.
Pour plus d'informations sur la configuration d'une infrastructure à clé publique, consultez l'article Best Practices for Implementing a Microsoft Windows Server 2003 Public Key Infrastructure (en anglais).