Utilisation d'une infrastructure à clé publique sur le serveur de transport Edge pour la sécurité d'un domaine

 

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

Dernière rubrique modifiée : 2012-07-23

La sécurité de domaine s'appuie sur une TLS (Transport Layer Security) mutuelle pour l'authentification. Une authentification TLS mutuelle réussie s'appuie sur une chaîne de certificat X.509 approuvée et validée pour les certificats TLS utilisés pour la sécurité de domaine.

Par conséquent, avant de pouvoir déployer la sécurité de domaine, vous devez configurer votre serveur de transport Edge et votre infrastructure à clé publique (PKI) X.509 pour prendre en charge l'approbation et la validation de certificat.

Important :

Une explication détaillée des technologies et concepts concernant la cryptographie et les certificats sort du cadre de cette rubrique. Avant de déployer une solution de sécurité qui utilise la cryptographie et les certificats X.509, il est conseillé de comprendre les concepts de base de l'approbation, de l'authentification, du chiffrement et de l'échange de clés publiques et privées. Pour plus d'informations, consultez les références répertoriées à la fin de cette rubrique.

Configuration des autorités de certification racines

Pour valider un certificat X.509 donné, vous devez approuver l'autorité de certification racine (CA) qui l'a émis. Une CA racine est la racine CA la mieux approuvée ; elle se trouve dans le haut de l'arborescence de CA. La CA racine a un certificat auto-signé. Lorsque vous exécutez une application qui s'appuie sur une authentification de certificats, chaque certificat doit avoir une chaîne de certificat qui se termine par un certificat dans le conteneur racine approuvé de l'ordinateur local. Le conteneur racine approuvé contient des certificats provenant des autorités de certification racines.

Pour l'envoi réussi de messages électroniques de domaines sécurisés, vous devez pouvoir valider le certificat X.509 du serveur de réception. De même, quand quelqu'un envoie des messages électroniques de domaines sécurisés à votre organisation, le serveur d'envoi pouvoir valider votre certificat.

Il existe deux types de CA racines approuvées que vous pouvez utiliser pour mettre en œuvre la sécurité de domaine. Les CA racines tierces intégrées et les CA racines privées.

Autorités de certification racines de confiance tierces

Microsoft Windows inclut une série de CA racines tierces intégrées. Si vous approuvez les certificats émis par ces CA racines tierces, cela signifie que vous pouvez vérifier les certificats qu'elles émettent. Si votre organisation et vos organisations partenaires utilisent l'installation par défaut d'Windows et approuvent les CA racines tierces intégrées, l'approbation est automatique. Dans ce cas, une configuration d'approbation supplémentaire n'est pas requise.

Autorités de certification racines de confiance privées

Une CA racine approuvée privée est une CA racine qui a été déployée par une infrastructure à clé publique privée ou interne. Par exemple, si votre organisation ou l'organisation avec laquelle vous échangez des messages électroniques de domaines sécurisés a déployé une infrastructure à clé publique interne avec son propre certificat racine, vous devez effectuer des configurations d'approbation supplémentaires.

Si des CA racines privées sont utilisées, vous devez mettre à jour la banque de certificats racines approuvés Windows sur le serveur de transport Edge pour que la sécurité de domaine fonctionne correctement.

Il existe deux façons de configurer une approbation : Approbation de racine directe et certification croisée. Vous devez comprendre que chaque fois que le service de transport sélectionne un certificat, il valide le certificat avant de l'utiliser. Par conséquent, si vous utilisez une CA racine privée pour émettre vos certificats, vous devez inclure la CA racine privée dans la banque de certificats racines approuvés sur chaque serveur de transport Edge qui envoie ou reçoit des messages électroniques de domaines sécurisés.

Approbation de racine directe

Si vous voulez approuver un certificat qui a été émis par une CA racine privée, vous devez ajouter manuellement ce certificat racine à la banque de certificats racines approuvés sur l'ordinateur serveur de transport Edge. Pour plus d'informations sur l'ajout manuel de certificats à la banque de certificats locale, consultez le fichier d'aide du logiciel enfichable Gestionnaire de certificats de la console MMC (Microsoft Management Console) Microsoft.

Certification croisée

Une certification croisée a lieu quand une CA signe un certificat qui est généré par une autre CA. Une certification croisée est utilisée pour établir l'approbation d'une infrastructure à clé publique à une autre. Dans le contexte d'une sécurité de domaine, si vous avez votre propre infrastructure à clé publique, au lieu d'utiliser une approbation manuelle directe pour une autorité racine d'un partenaire avec une infrastructure à clé publique interne, vous pouvez créer une certification croisée pour la CA partenaire sous votre autorité racine. Dans ce cas, l'approbation est établie parce que la certification croisée se lie à votre racine approuvée.

Vous devez comprendre que si vous avez une infrastructure à clé publique interne et si vous utilisez une certification croisée, vous devez manuellement mettre à jour la banque de certificats approuvés sur chaque serveur de transport Edge qui reçoit des messages électroniques de domaines sécurisés afin que chaque serveur de transport Edge puisse valider les certificats lorsqu'il reçoit des messages électroniques en provenance de partenaires qui sont approuvés par des certificats croisés.

Pour plus d'informations sur l'ajout manuel de certificats à la banque de certificats locale, consultez le fichier d'aide du logiciel enfichable Gestionnaire de certificats de la console MMC.

Configuration de l'accès à la liste de révocation de certificats

Chaque fois que le service de transport retrouve un certificat, il valide la chaîne de certificats et valide le certificat. La validation du certificat est un processus dans lequel plusieurs attributs du certificat sont confirmés. La plupart de ces attributs peuvent être confirmés sur l'ordinateur local par l'application qui demande le certificat. Par exemple, l'usage de ce certificat, les dates d'expiration du certificat et les attributs similaires peuvent être vérifiés en dehors du contexte d'une infrastructure à clé publique. Cependant, la vérification de la non-révocation du certificat doit être validée par la CA ayant émis le certificat. Par conséquent, la plupart des CA créent une liste de révocation de certificats (CRL) accessible au public pour valider l'état de révocation.

Pour un usage réussi de la sécurité de domaine, les CRL des CA que vous utilisez ou qui sont utilisées par vos partenaires doivent être accessibles aux serveurs de transport Edge qui envoient ou reçoivent des messages électroniques de domaines sécurisés. Si la vérification de la révocation échoue, le serveur de réception Exchange émet un rejet de protocole temporaire du message. Un échec temporaire de la révocation peut survenir. Par exemple, le serveur Web utilisé pour publier la CRL peut connaître une défaillance. Ou bien des problèmes de connectivité généraux entre le serveur de transport Edge et le point de distribution CRL peuvent faire échouer la vérification de la révocation. Par conséquent, des échecs temporaires de la révocation n'occasionnent des retards temporaires de la remise des messages que si le serveur d'envoi fait une nouvelle tentative plus tard. Toutefois, une validation des CRL est requise pour une transmission réussie de messages électroniques de domaines sécurisés.

Vous devez activer les scénarios suivants :

• Vos serveurs de transport Edge doivent avoir accès aux CRL pour les CA externes   Chaque partenaire avec lequel vous échangez des messages électroniques de domaines sécurisés doit avoir des CRL accessibles au public que le serveur de transport Edge de votre organisation peut contacter. Dans certains cas, les CRL ne sont accessibles qu'avec le protocole LDAP (Lightweight Directory Access Protocol). Dans la plupart des cas, avec les CA publiques, les CRL sont publiées via HTTP. Vérifiez que les ports de sortie et les proxy appropriés sont configurés pour que le serveur de transport Edge puisse contacter la CRL. Vous pouvez déterminer le protocole qu'un point de distribution de CRL donné accepte en ouvrant un certificat dans la MMC et en affichant le champ Points de distribution de CRL.

• Vous devez créer la CRL pour la CA qui émet vos certificats accessibles au public   Vous devez savoir que, même si un serveur de transport Edge extrait un certificat appartenant à votre organisation, il valide la chaîne de certificat pour valider le certificat. Par conséquent, la CRL de votre CA doit être disponible pour vos propres serveurs de transport Edge. En outre, tous les partenaires avec lesquels vous échangez des messages électroniques de domaines sécurisés doivent avoir accès à la CRL de la CA qui émet vos certificats.

Procédure de configuration des paramètres proxy pour WinHTTP

Les serveurs de transport Exchange 2010 dépendent des services Microsoft Windows HTTP (WinHTTP) sous-jacents pour la gestion de tout le trafic HTTP et HTTPS. Les serveurs de transport Hub et de transport Edge peuvent utiliser HTTP pour accéder aux mises à jour du filtrage standard du courrier indésirable Microsoft Exchange 2010 et pour la validation de la CRL.

Pour plus d'informations, consultez la rubrique Configurer les paramètres proxy pour WinHTTP.

Test de l'infrastructure à clé publique et configuration de proxy

Pour vérifier l'infrastructure à clé publique (PKI) et la configuration du proxy d'un serveur de transport Edge spécifique, utilisez Certutil.exe pour vérifier la chaîne de certificats pour le certificat de votre serveur de transport Edge. Certutil.exe est un outil de ligne de commande installé dans le cadre des services de certificats des systèmes d'exploitation de Windows Server 2008. Pour plus d'informations, consultez la rubrique Tester la configuration d'infrastructure à clé publique et du proxy.

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