Sélection de certificats TLS anonymes sortants

  • Article

 

S’applique à : Exchange Server 2010 SP2, Exchange Server 2010 SP3

Dernière rubrique modifiée : 2009-12-07

Cette rubrique décrit le processus de sélection des certificats TLS (Transport Layer Security) anonymes sortants dans Microsoft Exchange Server 2010. La sélection d’un certificat TLS anonyme sortant se produit dans les scénarios suivants :

  • Sessions SMTP entre des serveurs de transport Edge et des serveurs de transport Hub pour authentification

  • des sessions SMTP entre des serveurs de transport Hub pour le chiffrement uniquement à l’aide des clés publiques.

Pour la communication entre les serveurs de transport Hub, le TLS anonyme et les clés publiques des certificats permettent de chiffrer la session. Après qu’une session SMTP a été ouverte, le serveur de réception lance un processus de sélection de certificat pour déterminer le certificat à utiliser dans la négociation TLS. Le serveur de réception exécute également un processus de sélection de certificat. Pour plus d’informations sur ce processus, consultez la rubrique Sélection de certificats TLS anonymes entrants.

Envoi à partir d’un serveur de Transport Hub ou d’un serveur de Transport Edge

Toutes les étapes de sélection d’un certificat TLS anonyme sortant sont exécutées sur le serveur d’envoi. La figure suivante présente les étapes de ce processus.

Sélection d’un certificat TLS anonyme sortant

Sélection d’un certificat TLS anonyme sortant

  1. Après qu’une session SMTP a été ouverte à partir d’un serveur de transport Hub ou Edge, Microsoft Exchange appelle un processus pour charger les certificats.

    RemarqueRemarque :
    Pendant le chargement initial du certificat, le processus de sélection de certificat sortant est différent pour le rôle serveur de transport Edge et celui du rôle serveur de transport Hub. La figure représente le point de départ pour chaque rôle de serveur.

  2. Le processus de chargement de certificat est différent selon que la session SMTP est initiée à partir d’un serveur de transport Hub ou d’un serveur de transport Edge.

    Sur un serveur de transport Hub     Les contrôles suivants sont effectués :

    1. Le connecteur d’envoi auquel la session est connectée est contrôlé pour voir si la propriété SmartHostAuthMechanism est configurée pour ExchangeServer. Vous pouvez définir la propriété SmartHostAuthMechanism sur le connecteur d’envoi à l’aide de la cmdlet Set-SendConnector. Vous pouvez également définir la propriété SmartHostAuthMechanism sur ExchangeServer en sélectionnant Authentification Exchange Server dans la page Configurer les paramètres d’authentification d’un hôte actif d’un connecteur d’envoi spécifique. Pour ouvrir la page Configurer l’authentification d’un hôte actif, cliquez sur Modifier de l’onglet Réseau de la page de propriétés du connecteur d’envoi.

    2. La propriété DeliveryType du message est vérifiée pour déterminer si elle est définie sur la valeur SmtpRelayWithinAdSitetoEdge. Vous pouvez afficher la propriété DeliveryType en exécutant la cmdlet Get-Queue avec l’argument de format de liste (| Format-List).

      Les deux conditions suivantes doivent être remplies. Si ExchangeServer n’est pas activé comme mécanisme d’authentification ou si la propriété DeliveryType n’est pas définie sur SmtpRelayWithinAdSitetoEdge, le serveur de transport Hub d’envoi n’utilise pas le protocole TLS anonyme et aucun certificat n’est chargé. Si les deux conditions sont remplies, le processus de sélection de certificat passe à l’étape 3.

    Sur un serveur de transport Edge     Les contrôles suivants sont effectués :

    1. Le connecteur d’envoi auquel la session est connectée est contrôlé pour voir si la propriété SmartHostAuthMechanism est configurée pour ExchangeServer. Comme indiqué précédemment dans cette rubrique, vous pouvez définir la propriété SmartHostAuthMechanism sur le connecteur d’envoi à l’aide de la cmdlet Set-SendConnector. Vous pouvez également définir la propriété SmartHostAuthMechanism sur ExchangeServer en sélectionnant Authentification Exchange Server dans la page Configurer les paramètres d’authentification d’un hôte actif d’un connecteur d’envoi spécifique. Pour ouvrir la page Configurer les paramètres d’authentification d’un hôte actif, cliquez sur Modifier dans l’onglet Réseau de la page de propriétés du connecteur d’envoi.

    2. Le connecteur d’envoi auquel la session est connectée est vérifié pour déterminer si la propriété d’espace d’adressage SmartHost contient « - - ».

      Les deux conditions suivantes doivent être remplies. Si ExchangeServer n’est pas activé comme mécanisme d’authentification ou si la propriété d’espace d’adressage ne contient pas « - - », le serveur de transport Hub d’envoi n’utilise pas le protocole TLS anonyme et aucun certificat n’est chargé. Si les deux conditions sont remplies, le processus de sélection du certificat passe à l’étape 3.

  3. Microsoft Exchange interroge Active Directory pour récupérer l’empreinte du certificat sur le serveur. L’attribut msExchServerInternalTLSCert sur l’objet serveur stocke l’empreinte du certificat.

    Si l’attribut msExchServerInternalTLSCertne peut pas être lu ou si la valeur est null, Microsoft Exchange n’annonce pas X-ANONYMOUSTLS dans la session SMTP et aucun certificat n’est chargé.

    RemarqueRemarque :
    Si l’attribut msExchServerInternalTLSCert ne peut pas être lu ou si la valeur est null au démarrage du service de transport Microsoft Exchange, et non pendant la session SMTP, l’ID d’événement 12012 est consigné dans le journal des applications.

  4. Si une empreinte de certificat est trouvée, le processus de sélection de certificat recherche dans le magasin de certificats de l’ordinateur local un certificat correspondant à l’empreinte. Si le certificat est introuvable, le serveur n’annonce pas X-ANONYMOUSTLS, aucun certificat n’est chargé et l’ID d’événement 12013 est consigné dans le journal des applications.

  5. Après le chargement d’un certificat à partir du magasin de certificats, la date d’expiration du certificat est vérifiée. Le champ Valid to du certificat est comparé aux date et heure système actuelles. Si le certificat a expiré, l’ID d’événement 12015 est consigné dans le journal des applications. Dans ce cas, le processus de sélection du certificat n’échoue pas et procède aux vérifications suivantes.

  6. Le certificat est vérifié pour déterminer s’il est le plus récent dans le magasin de certificats de l’ordinateur local. Dans le cadre de ce contrôle, une liste de domaines est créée pour les domaines de certificats potentiels. La liste de domaines est basée sur la configuration d’ordinateur suivante :

    • nom de domaine complet (FQDN), tel que mail.contoso.com ;

    • nom d’hôte, tel que EdgeServer01 ;

    • FQDN physique, tel que EdgeServer01.contoso.com ;

    • nom d’hôte physique, tel que EdgeServer01.

      RemarqueRemarque :
      Si le serveur exécute l’équilibrage de charge Microsoft Windows, la clé de registre suivante est vérifiée à la place du paramètre DnsFullyQualifiedDomainName : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WLBS\Parameters\Interface\{GUID}\ClusterName

  7. Après la création d’une liste de domaines, le processus de sélection de certificat recherche dans le magasin de certificats tous les certificats dont le nom de domaine complet correspond. Dans cette liste, le processus de sélection de certificat identifie une liste de certificats admissibles. Des certificats admissibles doivent remplir les critères suivants :

    • Le certificat est conforme à la norme X.509, version 3 ou ultérieure.

    • Une clé privée est associée au certificat.

    • Le champ Objet ou Autre nom de l’objet contient le nom de domaine complet qui a été récupéré à l’étape 6.

    • Le certificat est activé pour une utilisation SSL (Secure Sockets Layer)/TLS. Pus spécifiquement, le service SMTP a été activé pour ce certificat à l’aide de la cmdlet Enable-ExchangeCertificate.

  8. Parmi les certificats admissibles, le meilleur est sélectionné sur la base de la séquence suivante :

    1. Triez les certificats admissibles en fonction de la date Valid from la plus récente. Le champ Valid from est un champ de version 1 dans le certificat.

    2. Le premier certificat d’infrastructure à clé publique (PKI) valide trouvé dans cette liste est utilisé.

    3. Si aucun certificat PKI n’est trouvé, le premier certificat auto-signé est utilisé.

  9. Une fois que le certificat le plus approprié est déterminé, une autre vérification est effectuée pour savoir si son empreinte correspond au certificat qui est stocké dans l’attribut msExchServerInternalTLSCert. Si tel est le cas, le certificat est utilisé pour X-ANONYMOUSTLS. Dans le cas contraire, l’ID d’événement 1037 est consigné dans le journal des applications. Cela n’entraînera pas pour autant l’échec de X-ANONYMOUSTLS.

 © 2010 Microsoft Corporation. Tous droits réservés.