Partager via

Utilisation de certificats dans un serveur Exchange 2007

  • Article

 

S’applique à : Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007

Dernière rubrique modifiée : 2008-05-19

Microsoft Exchange Server 2007 utilise des certificats afin de sécuriser de nombreux chemins d'accès de communication électronique. Cette rubrique sert d'introduction de bout en bout pour l'utilisation de certificats dans Exchange 2007. Les thèmes abordés sont les suivants :

  • utilisation des certificats dans Exchange 2007 ;

  • scénarios dans lesquels il est nécessaire d'acheter un certificat auprès d'une autorité de certification tierce ou de recourir au certificat auto-signé par défaut ;

  • utilisation des attributs de certificat par les composants Exchange 2007 et lien entre les propriétés de certificat et les champs d'extension de certificats X.509 ;

  • approbation et validation de certificats ;

  • procédure de création, importation et activation des certificats Exchange 2007 ;

  • mode de sélection de certificats par les composants Exchange à partir d'un magasin d'ordinateurs personnels.

Chaque section de cette rubrique contient des références et des liens vers de la documentation sur les certificats pour Exchange 2007.

Notification   La plupart de ce contenu a été adapté à partir des notes internes et de la documentation recueillis et fournis par Stuart Presley, ingénieur de support technique.

Sommaire

  • Composants Exchange 2007 utilisant les certificats pour chiffrer ou authentifier des sessions

  • Utilisation des certificats émis par des autorités de certification publiques et certificats auto-signés

  • Présentation des attributs de certificat et leur utilisation dans Exchange 2007

  • Approbation et validation de certificats

  • Création, importation et activation de certificats

  • Sélection de certificats

  • Pour plus d'informations

Composants Exchange 2007 utilisant les certificats pour chiffrer ou authentifier des sessions

Exchange 2007 utilise les certificats X.509 pour négocier des canaux de transport TLS (Transport Layer Security) et SSL (Secure Sockets Layer) sécurisés de communication pour les protocoles, tels que HTTPS, SMTP, POP et IMAP.

TLS est un protocole standard du groupe de travail IETF qui assure la confidentialité et la sécurité des communications entre deux applications communiquant sur un réseau. Le protocole TLS chiffre les communications et permet à des clients d'authentifier des serveurs ou, à titre facultatif, à des serveurs d'authentifier des clients. TLS est une version davantage sécurisée du protocole SSL sur lequel TLS est basé. SSL a été développé antérieurement par Netscape. Les deux protocoles ont les mêmes fonctions. Et la plupart des implémentations prennent en charge les deux protocoles pour assurer une compatibilité descendante avec les anciens clients basés sur SSL uniquement.

Les communications TLS peuvent être utilisées à des fins de confidentialité (chiffrement) uniquement ou à des fins de confidentialité et d'authentification. Les certificats X.509 peuvent être auto-signés ou émis par une autorité de certification X.509. Une autorité de certification X.509 peut être une autorité de certification publique tierce émettant des certificats ou une infrastructure à clé publique (PKI) déployée au sein de votre organisation. Sauf mention contraire, cette rubrique se réfère aux deux solutions sous le terme « autorité de certification ». Les autorités de certifications publiques tierces sont également appelées autorités de certification publiques.

Les composants Exchange 2007 suivants utilisent des certificats pour chiffrer ou authentifier des sessions :

  • SMTP   Les certificats sont utilisés à des fins de chiffrement et d'authentification pour la sécurité de domaine entre des organisations partenaires. Les certificats sont utilisés pour des connexions de confiance directe approuvées entre des serveurs de transport Hub et des serveurs de transport Edge. Les certificats sont utilisés entre des serveurs de transport Hub afin de chiffrer la session SMTP. Dans Exchange 2007, la confiance directe est la fonctionnalité d'authentification pour laquelle la présence du certificat dans le service d'annuaire Active Directory ou Active Directory Application Mode valide le certificat. Active Directory est considéré comme un mécanisme de stockage approuvé. Les certificats sont également utilisés pour les sessions TLS opportunistes entre des organisations. Pour plus d'informations, consultez la rubrique Fonction TLS et terminologie associée dans Exchange 2007.

  • Synchronisation EdgeSync   Un certificat auto-signé par Exchange 2007 permet de chiffrer la session de communication LDAP entre l'instance ADAM sur les serveurs de transport Edge et les serveurs Active Directory internes après que le service Microsoft Exchange EdgeSync a répliqué les données d'Active Directory vers l'instance ADAM sur le serveur de transport Edge. Un certificat auto-signé est un certificat signé par son propre créateur. Le service Microsoft Exchange EdgeSync est un service de synchronisation de données qui réplique périodiquement les données de configuration d'Active Directory vers un serveur de transport Edge abonné. Pour plus d'informations, consultez la rubrique Présentation du processus de synchronisation EdgeSync.

  • POP3 et IMAP4   Les certificats permettent d'authentifier et chiffrer la session entre des clients POP3 (Post Office Protocol version 3) et IMAP4 (Internet Message Access Protocol version 4rev1) et des serveurs Exchange. Pour plus d'informations, consultez la rubrique Gestion de la sécurité POP3 et IMAP4.

  • Messagerie unifiée   Les certificats permettent de chiffrer la session SMTP vers les serveurs de transport Hub et vers la passerelle IP de messagerie unifiée et Microsoft Office Communications Server 2007. Pour plus d'informations, consultez la rubrique Présentation de la sécurité VoIP de messagerie unifiée.

  • Découverte automatique   Les certificats permettent de chiffrer le chemin d'accès HTTP entre le client et le serveur d'accès au client. Pour plus d'informations, consultez le livre blanc : Service de découverte automatique Exchange 2007.

  • Applications d'accès au client   Les certificats permettent de chiffrer le chemin d'accès entre le serveur d'accès au client et divers clients HTTP, tels que Outlook Anywhere, Microsoft Outlook Web Access et des périphériques prenant en charge Microsoft Exchange ActiveSync. Pour plus d'informations, consultez la rubrique Gestion de la sécurité de l'accès au client.

Pour plus d'informations sur le chiffrement et l'authentification de chaque chemin de données dans Exchange 2007, consultez la rubrique Référence de sécurité du chemin d'accès aux données.

Retour au début

Utilisation des certificats émis par des autorités de certification publiques et certificats auto-signés

L'objectif de cette section est de présenter rapidement l'utilisation des certificats par Exchange 2007. Si vous avez déjà parcouru cette section, vous devez savoir, en fonction des composants Exchange activés et des clients pris en charge, quel certificat vous devez vous procurer auprès d'une autorité de certification publique. Cette section fournit également le contexte général en relation avec le contenu technique à venir.

Cette section, qui doit vous permettre de déterminer rapidement vos besoins en matière de certificats en relation avec les autorités de certification publiques, est nécessairement courte. À des fins de concision, de nombreuses généralisations sur les certificats et les technologies associées permettent d'illustrer l'utilisation de certificats dans Exchange 2007. Si vous ne comprenez pas les concepts évoqués dans cette section, assurez-vous de lire la suite de la rubrique et de consulter la documentation référencée.

Généralement, tout composant Exchange 2007 utilisant l'authentification Kerberos, de confiance directe ou NTLM peut utiliser un certificat auto-signé à des fins de chiffrement. Dans cette rubrique, de tels composants sont appelés composants Exchange 2007 internes. Interne fait référence au fait que les chemins de données sont entre les serveurs Exchange 2007 et au sein du réseau d'entreprise défini par Active Directory.

Il est recommandé de déployer un certificat émis par une autorité de certification publique lorsque vos utilisateurs ont accès à des composants Exchange requérant une authentification et un chiffrement en dehors du pare-feu de l'entreprise. Par exemple, tous les clients pris en charge par le rôle serveur d'accès au client, tels que Exchange ActiveSync, POP3, IMAP4 et Outlook Anywhere, doivent être sécurisés via un certificat émis par une autorité de certification publique. Dans cette rubrique, de tels composants sont appelés composants Exchange 2007 externes. Externe fait référence au fait que les chemins de données entre les clients et les serveurs Exchange 2007 traversent le pare-feu d'entreprise et s'étendent vers Internet.

Les composants internes utilisent des certificats auto-signés

Comme indiqué ci-avant, de nombreux composants d'Exchange 2007 utilisent des certificats. Généralement, tous les chemins de données Exchange internes sécurisés par des certificats ne requièrent pas de certificat émis par une autorité de certification publique.

L'ensemble du trafic SMTP interne et de messagerie unifiée est sécurisé via des certificats auto-signés installés lors de l'exécution du programme d'installation du serveur Exchange 2007. Bien que ces certificats doivent être renouvelés sur une base annuelle à l'aide de la cmdlet New-ExchangeCertificate, il n'est pas nécessaire de recourir à un certificat émis par une autorité de certification publique pour exécuter les composants de messagerie Exchange internes par défaut.

Notes

Les certificats auto-signés créés par Exchange expirent au bout d'un an. Les composants internes qui s'appuient sur des certificats auto-signés par défaut continuent de fonctionner même en cas d'expiration du certificat auto-signé. Toutefois, lorsque le certificat auto-signé a expiré, les événements sont consignés dans l'Observateur d'événements. Il est recommandé de renouveler les certificats auto-signés avant leur expiration.

Exchange 2007 inclut un ensemble de cmdlets permettant de créer, demander et gérer les certificats TLS. Pour plus d'informations sur ces cmdlets, consultez la section Cmdlets liées aux certificats plus loin dans cette rubrique. Par défaut, ces certificats sont auto-signés. Comme expliqué plus haut, un certificat auto-signé est signé par son propre créateur. Dans Exchange 2007, le certificat auto-signé est créé par l'ordinateur exécutant Microsoft Exchange à l'aide de l'API de certificat Windows sous-jacent. Les certificats étant auto-signés, les certificats résultants sont généralement moins fiables que ceux issus par une autorité de certification. Par conséquent, il est recommandé de n'utiliser les certificats auto-signés que dans les scénarios internes suivantes :

  • sessions SMTP entre des serveurs de transport Hub : un certificat n'est utilisé qu'à des fins de chiffrement de la session SMTP. L'authentification est assurée par le protocole Kerberos.

  • sessions SMTP entre des serveurs de transport Hub et un serveur de transport Edge : un certificat est utilisé à des fins de chiffrement de la session SMTP et d'authentification de confiance directe.

  • synchronisation EdgeSync entre les serveurs de transport Edge et Active Directory : un certificat permet de chiffrer la session de communication LDAP entre l'instance ADAM sur les serveurs de transport Edge et les serveurs Active Directory internes après que le service Microsoft Exchange EdgeSync a répliqué les données d'Active Directory vers l'instance ADAM sur le serveur de transport Edge.

  • communications de messagerie unifiée : un certificat est utilisé à des fins de chiffrement du trafic SIP (Session Initiation Protocol) et RTP (Realtime Transport Protocol) entre les serveurs de messagerie unifiée et les passerelles IP de messagerie unifiée, les IP PBX (Private Branch eXchange) et les ordinateurs exécutant Office Communications Server 2007. Le certificat permet également de chiffrer le trafic SMTP lorsque des messages vocaux ou de télécopie sont envoyés de serveurs de messagerie unifiée vers des serveurs de transport Hub.

  • serveur d'accès au client accessible uniquement par des clients internes.

L'accès client externe vers Exchange nécessite des certificats émis par une autorité de certification publique

Les composants Exchange internes peuvent s'appuyer sur des certificats auto-signés car ils ne sont pas utilisés à des fins d'authentification. L'authentification pour la plupart des composants Exchange est assurée par Kerberos ou NTLM. Dans le cadre de la communication entre un serveur de transport Edge et un serveur de transport Hub, l'authentification de confiance directe est utilisée. Ceci est possible grâce à un certificat et au fait que la clé publique du serveur de transport Edge est stockée dans Active Directory, qui est une banque approuvée. Sinon, les certificats auto-signés permettent de fournir une clé éphémère pour le chiffrement des chemins de données entre des composants Exchange.

Toutefois, pour l'accès de clients externes d'Internet vers le réseau dans lequel Exchange est hébergé, il est nécessaire d'utiliser la validation de certificats traditionnelle. Il est recommandé d'utiliser un certificat émis par une autorité de certification publique à des fins de validation de l'approbation. En fait, lorsque l'authentification de certificat est requise, l'utilisation d'un certificat auto-signé est fortement déconseillée. Il est recommandé d'utiliser un certificat émanant d'une autorité de certification publique pour :

  • l'accès client POP3 et IMAP4 vers Exchange ;

  • Outlook Web Access ;

  • Outlook Anywhere ;

  • Exchange ActiveSync ;

  • le service de découverte automatique ;

  • la sécurité de domaine.

Pour tous, il est recommandé d'utiliser une autorité de certification publique approuvée par tous les clients par défaut.

La cmdlet New-ExchangeCertificate génère une demande de certificat en fonction des spécifications de l'autorité de certification publique tierce qui émet votre certificat.

Pour plus d'informations, consultez les rubriques suivantes :

Le reste de la section fournit des informations sur la manière de déterminer le type de certificat public que vous pouvez acheter et indique si vous devez acheter plusieurs certificats pour sécuriser les clients que votre organisation utilise pour accéder à Exchange 2007.

Type et nombre de certificats émis par une autorité de certification publique adaptés à votre déploiement

La sélection du certificat approprié émis par une autorité de certification pour votre organisation dépend des facteurs suivants :

  • Prise en charge par les clients des noms génériques dans les certificats   Demandez-vous : quels clients vont être pris en charge ? Comme signalé ci-avant, dans ce contexte, les « clients » font référence aux clients qui accèdent à Exchange à partir d'Internet.

  • Espace de noms de votre organisation   De quelle manière est configuré l'espace de noms de vos services IIS ?

  • Source de votre certificat   Auprès de quelle autorité allez-vous vous procurer votre certificat ? L'autorité de certification publique choisie prend-elle en charge les caractères génériques dans les champs Objet et Autre nom de l'objet ? Si ce n'est pas le cas, prend-elle en charge l'utilisation des autres noms d'objet ?

Les sections suivantes examinent les facteurs abordés ci-avant de manière approfondie.

Prise en charge par les clients des noms génériques dans les certificats

Les noms génériques peuvent être utilisés dans les extensions Objet et Autre nom de l'objet des certificats X.509. Pour plus d'informations sur les noms génériques, consultez « CertificateDomains » dans la section Présentation des attributs de certificat et leur utilisation dans Exchange 2007 plus loin dans cette rubrique.

Après avoir identifié les clients pris en charge par votre organisation, vous pouvez déterminer s'ils prennent en charge les certificats dans lesquels des noms génériques sont utilisés dans le certificat de serveur auquel le client se connecte.

Si votre client prend en charge l'utilisation des noms génériques dans le certificat, la planification globale des certificats dans votre organisation est grandement simplifiée. Si tous vos clients prennent en charge les noms génériques dans les certificats et si votre organisation utilise un nom de domaine unique, vous ne devez pas envisager de planification des espaces de noms dans votre stratégie de déploiement de certificats. Créez plutôt un seul certificat prenant en charge votre espace de noms avec un caractère générique. Par exemple, si les clients exécutant Outlook Web Access utilisent mail.contoso.com/owa pour accéder à leur messagerie et si les clients POP3 utilisent pop.contoso.com, un certificat unique avec un Objet au format générique *.contoso.com prend en charge les deux clients.

Les clients Microsoft suivants prennent en charge les noms génériques dans les certificats :

importantImportant :
Les clients exécutant Windows Mobile 5.0 ne prennent pas en charge un canal chiffré vers les serveurs pour lesquels des noms génériques sont utilisés dans le certificat.

Si un client pris en charge par votre organisation ne prend pas en charge les noms génériques dans le certificat de serveur et que vous devez prendre en charge plusieurs espaces de noms de clients, vous devez soit

  1. acheter un certificat contenant plusieurs noms, tel que mail.contoso.com, pop.contoso.com et mobile.contoso.com dans l'extension Autre nom de l'objet.

  2. acheter un certificat pour chaque entité de l'espace de noms auquel un client se connecte.

Planification de l'espace de noms de votre organisation

Tous les clients nécessitent une URL ou un nom de domaine complet (FQDN) auquel se connecter. Chaque chemin d'accès auquel les clients se connectent doit être associé à un certificat valide contenant le nom d'hôte, le nom NetBIOS, le nom de domaine complet ou le nom habituel de l'hôte auquel le client se connecte. Le processus consistant à déterminer la liste des noms à inclure dans le certificat est appelé planification de l'espace de noms.

Généralement, la planification d'espace de noms pour de grandes organisations prenant en charge de nombreux clients différents et s'étendant sur plusieurs régions avec plusieurs serveurs est plus complexe que la planification d'espaces de noms pour les organisations plus petites.

Vous devez comprendre la planification d'espace de noms de certificats afin de définir quels noms d'hôte doivent être inclus dans l'extension Autre nom de l'objet du certificat que vous utilisez pour sécuriser les connexions entrantes vers Exchange 2007.

Pour plus d'informations, consultez la rubrique Planification de l'espace de noms pour Exchange Server 2007.

Où obtenir votre certificat

Comme mentionné précédemment, pour l'accès externe des clients, il est recommandé d'acheter un certificat auprès d'une autorité de certification tierce.

Lorsque vous évaluez les autorités de certification, tenez compte des critères suivants :

  • L'autorité de certification autorise-t-elle les noms génériques dans le certificat ? Si vos clients peuvent prendre en charge les noms génériques dans le certificat, l'achat d'un certificat auprès d'une autorité de certification prenant en charge les noms génériques est la méthode la plus simple pour déployer des clients sécurisés.

  • L'autorité de certification prend-elle en charge l'extension Autre nom de l'objet ? Si les conditions suivantes sont remplies, il est préférable d'utiliser un certificat qui prend en charge plusieurs noms dans l'extension Autre nom de l'objet :

    • Vous devez prendre en charge des clients qui ne prennent pas en charge les noms génériques dans le certificat.

    • Vous possédez plusieurs chemins d'accès d'ordinateur hôte auxquels les clients doivent se connecter.

    Microsoft a mis en place un partenariat avec des autorités de certification publiques afin de fournir un certificat de communications unifiées. Pour obtenir une liste actualisée des autorités de certification qui prennent en charge les certificats de communications unifiées, consultez l'article 929395 de la Base de connaissances Microsoft sur les partenaires pour les certificats de communications pour Exchange 2007 et Communications Server 2007.

  • L'autorité de certification offre-t-elle un niveau élevé de vérification d'authenticité ? Certaines autorités de certification sont très peu onéreuses. D'autres autorités de certification pratiquent des tarifs annuels de plusieurs centaines d'euros pour un certificat. Étant donné que vous comptez sur l'intégrité de ce certificat pour authentifier le trafic entrant dans votre organisation, il est recommandé de ne pas sélectionner une autorité de certification publique uniquement sur la base des tarifs qu'elles pratiquent. Évaluez et comparez attentivement les services offerts par chaque autorité de certification et leur réputation avant de prendre une décision.

Retour au début

Présentation des attributs de certificat et leur utilisation dans Exchange 2007

Le fait de comprendre les divers attributs des certificats vous aidera à appréhender la manière dont Exchange utilise les certificats. Cette compréhension vous aidera par la suite à planifier les besoins en matière de certificat de votre organisation Exchange, ainsi qu'à résoudre les problèmes que vous pouvez rencontrer.

Les certificats X.509 ont deux types d'attributs.

  • Les champs de certificat sont les attributs compris dans les données signées du certificat X.509. Ces champs sont protégés par la signature et leur valeur ne peut pas être modifiée sans signer ou émettre à nouveau le certificat.

  • Les propriétés de certificat sont des attributs qui sont des métadonnées du certificat ou de la clé privée. Certaines propriétés sont intrinsèques au certificat ou à la clé privée, comme par exemple l'empreinte des certificats. Toutefois, vous pouvez modifier les propriétés du certificat sans qu'il soit nécessaire de le signer à nouveau.

    Par exemple, la cmdlet Enable-ExchangeCertificate vous permet d'ajouter des services aux propriétés des certificats après leur création. Vous pouvez activer les certificats de sorte qu'ils puissent être utilisés par les services Internet, tels que Outlook Web Access ou Exchange ActiveSync, par le protocole SMTP, tel que la confiance directe ou la sécurité de domaine, les protocoles IMAP et POP, et la messagerie unifiée. L'activation d'un certificat pour un service spécifique met à jour les propriétés du certificat. Pour plus d'informations, consultez la rubrique Enable-ExchangeCertificate.

Vous pouvez afficher ces attributs en exécutant la cmdlet Get-ExchangeCertificate avec l'argument |FL sur un certificat donné. Si vous exécutez Exchange 2007 RTM, vous devez exécuter la cmdlet avec l'argument |FL* afin d'afficher toutes les données d'attribut.

Certains champs et propriétés spécifiés dans la sortie de la cmdlet Get-ExchangeCertificate mappent vers des champs d'extension X.509 que vous pouvez afficher à l'aide du Gestionnaire de certificats dans la console MMC (Microsoft Management Console). Pour plus d'informations sur le Gestionnaire de certificats, consultez la rubrique Procédure d'ajout du Gestionnaire de certificats à Microsoft Management Console (MMC). Pour plus d'informations sur la cmdlet Get-ExchangeCertificate, consultez la rubrique Get-ExchangeCertificate.

Champs de certificat

Comme indiqué ci-avant, les champs de certificat sont les attributs compris dans les données signées du certificat X.509. Cette section présente les champs de certificat utilisés par les services Microsoft Exchange et affichés dans la sortie de la cmdlet Get-ExchangeCertificate.

Certains de ces champs sont également des paramètres que vous pouvez définir lorsque vous créez un certificat ou une demande de certificat à l'aide de la cmdlet New-ExchangeCertificate. Pour plus d'informations sur la cmdlet New-ExchangeCertificate, consultez la rubrique New-ExchangeCertificate.

Chaque champ de certificat dans cette section est répertorié en fonction de la sortie de la cmdlet Get-ExchangeCertificate. Chaque nom de champ de certificat Exchange dans cette section mappe vers un nom d'extension de certificat X.509.

Issuer

Ce champ contient le nom courant qui identifie l'émetteur du certificat. Les certificats auto-signés créés par Exchange au cours de l'installation ou par la cmdlet New-ExchangeCertificate affichent cn=hostname, où hostname est le nom du serveur local.

Les certificats émis par les autorités de certification affichent généralement le nom complet courant de l'autorité de certification dans le champ Issuer.

Le nom d'extension de certificat X.509 est également Issuer.

Le champ Issuer ne possède pas de paramètre correspondant que vous pouvez définir dans la cmdlet New-ExchangeCertificate. Le champ Issuer est spécifié par l'entité qui émet le certificat.

Subject

Ce champ identifie l'objet du certificat. Subject est une chaîne X.500 qui représente généralement un nom unique utilisé pour accéder au service qui utilise le certificat. Lorsqu'un certificat est créé par la cmdlet New-ExchangeCertificate, si l'objet n'est pas indiqué explicitement, Subject sera la première valeur répertoriée sous le paramètre DomainName lorsque vous exécutez la cmdlet New-ExchangeCertificate. Les champs X.500 suivants doivent être présents :

  • C = Pays

  • ST = État

  • L = Emplacement

  • O = Organisation

  • OU = Unité d'organisation

  • CN = Nom courant

Certains de ces champs sont requis lorsque vous générez des demandes de certificat pour des autorités de certification tierces. Pour obtenir des explications approfondies sur le champ Subject, consultez la rubrique Création d’un certificat ou demande de certificat pour TLS.

Si vous exécutez Microsoft Internet Security and Acceleration (ISA) Server 2006 devant Exchange à des fins de pontage, assurez-vous d'avoir consulté le message publié sur le blog relatif au fait que des certificats avec plusieurs entrées Autre nom de l'objet peuvent interrompre la publication Web avec ISA Server afin d'obtenir des informations supplémentaires sur les noms d'objet et le comportement d'ISA Server.

Notes

  Le contenu et l'URL des blogs et pages Wiki sont susceptibles d'être modifiés sans préavis.

Lorsqu'Exchange génère un certificat auto-signé sans argument utilisateur, il crée un certificat qui contient le nom d'objet CN=hostname.

Le nom d'extension de certificat X.509 est également Subject.

Définissez le champ Subject en spécifiant le paramètre SubjectName dans la cmdlet New-ExchangeCertificate.

CertificateDomains

Le champ CertificateDomains identifie tous les noms de domaine DNS associés à un certificat. Les noms de domaine DNS peuvent être indiqués dans l'attribut (cn=) de nom courant de l'objet ou dans l'extension Autre nom de l'objet d'un certificat. La sortie de la cmdlet Get-ExchangeCertificate affiche l'union du domaine dans le champ Subject et tout domaine trouvé dans l'autre nom de l'objet.

Les valeurs du champ CertificateDomains peuvent inclure le nom d'hôte ou le nom de domaine complet utilisé pour accéder au serveur. Pour utiliser un certificat, le nom de domaine complet qui permet à un client de se connecter au serveur doit apparaître dans le champ CertificateDomains du certificat.

Par exemple, si un client se connecte à un serveur via le protocole POP3 avec mail.fourthcofee.com comme nom de serveur, le certificat associé aux paramètres POP3 peut contenir mail.fourthcoffee.com dans le champ CertificateDomains.

Vous pouvez également trouver des certificats avec des noms génériques, par exemple *.fourthcoffee.com. Ceci est un domaine acceptable. Toutefois, vous devez savoir que certains clients hérités et périphériques mobiles ne prennent pas en charge les noms génériques dans un certificat et peuvent donc ne pas prendre en charge les domaines génériques.

Notes

Le champ Autre nom de l'objet n'est pas exposé directement via Exchange. Vous ne pouvez l'afficher que dans le Gestionnaire de certificats dans la console MMC ou via le Gestionnaire des services Internet (IIS). Le Gestionnaire des services Internet (IIS) permet également d'afficher les certificats liés à un site Web, tels que ceux utilisés par les services Internet pour Outlook Web Access, Exchange ActiveSync ou le service de découverte automatique.

Pour obtenir des explications approfondies sur l'utilisation des autres noms de l'objet et des noms génériques dans les certificats, consultez la rubrique Création d’un certificat ou demande de certificat pour TLS. En outre, l'article du blog de l'équipe Exchange sur la génération d'un certificat avec une autorité de certification tierce pour Exchange 2007 donne des conseils pratiques sur la création d'une demande de certificat avec plusieurs autres noms d'objet.

Notes

  Le contenu et l'URL des blogs et pages Wiki sont susceptibles d'être modifiés sans préavis.

Le nom d'extension de certificat X.509 est Autre nom de l'objet ; toutefois, comme indiqué ci-avant, la sortie de la cmdlet Get-ExchangeCertificate ajoute également la valeur contenue dans l'extension de certificat Objet à la liste des noms dans le champ CertificateDomains.

Définissez le champ CertificateDomains en spécifiant les paramètres DomainName et Subject de la cmdlet New-ExchangeCertificate.

NotBefore et NotAfter

Les valeurs des champs NotBefore et NotAfter représentent une plage de dates de validité du certificat. Si la date actuelle est ultérieure à la date NotAfter, cela signifie que le certificat a expiré. Microsoft Exchange peut continuer à utiliser les certificats expirés mais les clients génèrent des avertissements et le serveur consigne les événements appropriés dans le journal des événements.

Le nom d'extension de certificat X.509 qui mappe vers la valeur NotBefore est Valid from. Le nom d'extension de certificat X.509 qui mappe vers la valeur NotAfter est Valid to.

Les champs NotBefore et NotAfter n'ont pas de paramètres correspondants que vous pouvez définir dans la cmdlet New-ExchangeCertificate. Ces champs sont définis par l'entité qui émet le certificat. Les certificats auto-signés générés par le programme d'installation d'Exchange ou par la cmdlet New-ExchangeCertificate sont valides pendant un an.

CertificateRequest

Cette valeur n'est présente que dans les certificats en état de demande. Les demandes de certificat ne sont pas des certificats X.509 valides et ne peuvent donc pas être utilisées par Exchange.

Le champ CertificateRequest est activé en spécifiant le paramètre booléen GenerateRequest de la cmdlet New-ExchangeCertificate.

Propriétés de certificat

Comme indiqué ci-avant, les propriétés de certificat sont des attributs qui sont des métadonnées du certificat ou de la clé privée. Certaines propriétés sont intrinsèques au certificat ou à la clé privée, comme par exemple l'empreinte des certificats. Toutefois, vous pouvez modifier les propriétés du certificat sans qu'il soit nécessaire de le signer à nouveau.

À l'exception de la propriété Thumbprint, aucune propriété de certificat Exchange ne correspond à une extension de certificat X.509.

Cette section présente les propriétés de certificat.

IsSelfSigned

La propriété IsSelfSigned indique si un certificat est auto-signé ou non. Un certificat auto-signé est généralement un certificat racine. Il s'agit d'un certificat unique dans la chaîne de certificats. Dans Exchange, le certificat auto-signé correspond généralement aux types de certificats suivants :

  • un certificat généré au cours de l'installation d'Exchange sur un serveur sans certificat qualifiant ;

  • un certificat issu de l'exécution de la cmdlet New-ExchangeCertificate.

Lorsque les rôles serveur de transport Hub ou Edge, de messagerie unifiée ou d'accès au client sont installés, le programme d'installation d'Exchange génère un certificat auto-signé. Si un certificat valide existe dans le magasin de certificats Personnel de l'ordinateur hôte, le certificat existant est utilisé, contrairement au certificat auto-signé généré par le programme d'installation d'Exchange. Les valeurs valides sont True ou False.

RootCAType

La propriété RootCAType identifie le type d'autorité de certification ayant émis le certificat. Si le paramètre IsSelfSigned est défini sur True, la valeur de la propriété RootCAType doit être None. Sinon, le certificat peut provoquer des résultats inattendus dans le cadre du processus de sélection du certificat. D'autres valeurs possibles sont les suivantes :

  • Registry   Une autorité de certification racine PKI privée interne, installée manuellement dans le magasin de certificats.

  • ThirdParty   Une autorité de certification racine tierce publique.

  • GroupPolicy   Une autorité de certification racine PKI privée interne, déployée via la stratégie de groupe.

  • Enterprise   Une autorité de certification racine PKI privée interne, déployée avec Active Directory.

  • Unknown   Exchange ne peut pas déterminer le type de certificat installé.

Afin de diagnostiquer des stratégies d'approbation incohérentes, vous devez comprendre la procédure d'installation du certificat racine sur un ordinateur. En raison de ces incohérences, il se peut que les certificats soient validés sur certains serveurs et ne le soient pas sur d'autres.

Par exemple, la valeur Registry indique une installation manuelle du certificat sur un seul serveur. Cela peut provoquer des incohérences si le certificat n'a pas été installé sur les autres serveurs de l'organisation. Il est recommandé de distribuer des certificats à tous les ordinateurs à l'aide de la stratégie de groupe ou d'Active Directory.

Services

La propriété Services identifie les services avec lesquels le certificat peut être utilisé. Les valeurs valides sont SMTP, POP, IMAP, UM et IIS.

Définissez la valeur dans le champ Services en spécifiant le paramètre Services dans la cmdlet Enable-ExchangeCertificate. Pour plus d'informations, consultez la rubrique Enable-ExchangeCertificate.

Status

La propriété Status identifie la validité du certificat. Le champ Status permet de résoudre les problèmes liés aux certificats. Si la valeur Status d'un certificat est différente de Valid, aucun service ne pourra utiliser ce certificat via le serveur Exchange. La propriété Status peut avoir les valeurs suivantes :

  • Unknown   Cet état indique généralement l'impossibilité de vérifier l'état du certificat car la liste de révocation des certificats est indisponible ou ce serveur ne peut pas s'y connecter. Assurez-vous que l'ordinateur peut se connecter à l'autorité de révocation des certificats. Pour plus d'informations, consultez la rubrique Procédure de configuration de paramètres de proxy pour WinHTTP.

  • Valid   Le certificat fonctionne correctement.

  • Revoked   La liste de révocation de certificats indique que ce certificat a été révoqué. Vous devez générer un nouveau certificat.

  • DateInvalid   Cet état indique que l'heure système est incorrecte, que le certificat a expiré ou que l'heure du système ayant signé le fichier est incorrecte. Vérifiez que les conditions suivantes sont vraies :

    • L'horloge de l'ordinateur local est exacte.

    • Le certificat n'a pas expiré.

    • L'horloge du système d'envoi est exacte.

    Si le certificat a expiré, vous devez en générer un nouveau.

  • Untrusted   Cet état indique qu'il ne s'agit pas d'un certificat auto-signé. Toutefois, il est signé par une autorité de certification non approuvée par l'ordinateur local. Vous devez ajouter le certificat de l'autorité de certification à la banque Autorités de certification racines de confiance sur l'ordinateur. Pour plus d'informations sur l'ajout manuel de certificats à le magasin de certificats locale, consultez le fichier d'aide du Gestionnaire de certificats de la console MMC.

  • Invalid   Le certificat a été invalidé en raison d'un autre problème, tel qu'un certificat non approuvé, non valide ou révoqué situé dans le chemin d'accès du certificat.

Pour plus d'informations sur la résolution de problèmes, consultez les rubriques suivantes :

HasPrivateKey

La propriété HasPrivateKey indique si le certificat installé possède une clé privée. Ceci est très important car le service de transport Microsoft Exchange, le service POP3 Microsoft Exchange et le service IMAP4 Microsoft Exchange n'utilisent pas de certificat sans clé privée.

Thumbprint

La propriété Thumbprint est une chaîne unique qui identifie le certificat. Si un même certificat est installé sur plusieurs serveurs Exchange, vous pouvez les identifier grâce à leur empreinte. Généralement, un même certificat est installé sur plusieurs serveurs Exchange lorsque plusieurs serveurs de transport Edge acceptent du courrier doté d'un nom de domaine complet identique, tel que mail.fourthcoffee.com. Il est beaucoup plus rentable d'installer un même certificat sur plusieurs serveurs que de demander de nouveaux certificats pour chaque serveur. Toutefois, le certificat doit posséder une clé privée exportable.

La propriété Thumbprint permet de spécifier un certificat pour les cmdlets suivantes :

Le nom d'extension de certificat X.509 qui mappe vers la propriété Thumbprint est également Thumbprint.

Retour au début

Approbation et validation de certificats

Pour utiliser un certificat à des fins d'authentification, il doit être validé et approuvé.

Pour valider un certificat X.509 donné, vous devez approuver l'autorité de certification racine qui l'a émis. Une autorité de certification racine est l'autorité la plus approuvée. Elle se trouve en haut d'une autorité de certification. L'autorité de certification 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.

Un certificat est chaîné à une autorité de certification par un autre certificat. Ce certificat peut également avoir été émis par une autorité de certification à laquelle il est donc chaîné. Cette chaîne de certificats est également appelé chemin d'accès de certification. Chaque certificat du chemin d'accès de certification doit être valide pour que le certificat le soit également. En outre, le certificat en haut de la chaîne doit être une autorité de certification racine approuvée.

Il existe deux types d'autorités de certification racines approuvées que vous pouvez utiliser pour mettre en oeuvre des applications qui s'appuient sur l'authentification de certificats : Les autorités de certification racines publiques tierces et les autorités de certification racines privées.

Autorités de certification racines publiques tierces

Windows, Windows Mobile et divers systèmes d'exploitation tiers incluent une série d'autorités de certification racines publiques tierces intégrées. Si vous approuvez les certificats émis par ces autorités de certification racines publiques tierces, vous pouvez vérifier les certificats qu'elles émettent.

L'approbation est automatique si les conditions suivantes sont vérifiées :

  • Votre organisation utilise l'installation Windows par défaut.

  • Le logiciel client et les périphériques mobiles utilisés dans votre organisation approuvent également les autorités de certification racines publiques tierces.

Dans ce cas, une configuration d'approbation supplémentaire n'est pas requise.

Autorités de certification racines de confiance privées

Une autorité de certification racine approuvée privée est une autorité de certification racine qui a été déployée par une infrastructure à clé publique privée ou interne. Par exemple, si votre organisation a déployé une infrastructure à clé publique interne avec son propre certificat racine, vous devez effectuer des configurations d'approbation supplémentaires.

Il est généralement recommandé d'utiliser des certificats émis par une infrastructure à clé publique privée pour les applications clientes qui prennent en charge les connexions externes vers votre organisation.

Si des autorités de certification racines privées sont utilisées, vous devez mettre à jour le magasin de certificats Racines approuvés sur tous les périphériques, clients et systèmes d'exploitation Windows nécessitant une authentification de certificats.

Il existe deux façons de configurer une approbation : approbation de racine directe et certification croisée.

Approbation de racine directe

Si vous voulez approuver un certificat émis par une autorité de certification racine privée, vous devez ajouter manuellement ce certificat racine au magasin de certificats Racines approuvés sur l'ordinateur exécutant Windows. Dans certains cas, vous pouvez également ajouter un certificat racine au magasin de racines approuvées des clients mobiles. Pour plus d'informations sur l'ajout manuel de certificats au magasin de certificats local sur un ordinateur exécutant Windows, consultez le fichier d'aide du Gestionnaire de certificats de la console MMC. Pour plus d'informations sur la procédure d'installation de certificats sur des périphériques Windows Mobile, consultez la rubrique Comment faire pour installer des certificats racines sur un appareil Windows Mobile.

importantImportant :
Il est probable que vous ne puissiez pas installer de certificats sur tous les ordinateurs et périphériques dont se servent les utilisateurs pour accéder à Exchange. Par exemple, certains utilisateurs peuvent accéder à Outlook Web Access à partir d'une borne d'accès à Internet ou de l'ordinateur d'un ami. Dans ce scénario, les utilisateurs reçoivent un avertissement mais peuvent continuer à accéder à leur courrier électronique. Ce comportement n'est pas recommandé car il habitue les utilisateurs à ignorer les avertissements de certificat. Il est donc recommandé d'utiliser des certificats émis par des autorités de certification tierces approuvées.

Certification croisée

Une certification croisée se produit lorsqu'une autorité de certification signe un certificat généré par une autre autorité de certification. Une certification croisée est utilisée pour établir l'approbation d'une infrastructure à clé publique à une autre. Si vous avez votre propre infrastructure à clé publique, plutôt que d'utiliser une approbation manuelle directe pour une autorité de certification racine d'une autre infrastructure à clé publique privée, vous pouvez créer une certification croisée pour l'autre autorité de certification sous votre autorité de certification racine. Dans ce cas, l'approbation est établie car la certification croisée est chaînée à votre autorité de certification racine approuvée.

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

Lorsqu'un service spécifique, tel que le service de transport Microsoft Exchange dans le scenario SMTP/TLS ou les services Internet (IIS) dans le scénario HTTPS, extrait un certificat, il valide la chaîne de certificats et 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 l'autorité de certification ayant émis le certificat. Par conséquent, la plupart des autorités de certification créent une liste de révocation de certificats (CRL) accessible au public pour valider l'état de révocation.

Pour une authentification réussie avec les certificats, les listes de révocation de certificats pour les autorités de certification que vous utilisez doivent être accessibles aux services qui authentifient le client. Si la vérification de révocation échoue, le service d'authentification échoue également.

Vos serveurs d'authentification doivent pouvoir accéder aux listes de révocation de certificats pour les autorités de certification externes.

Toutes les autorités de certification publiques possèdent des listes de révocation de certificats que les serveurs de votre organisation peuvent contacter. Dans certains cas, les listes de révocation de certificats pour les infrastructures à clé publique internes privées ne sont disponibles qu'avec le protocole LDAP (Lightweight Directory Access Protocol). Dans la plupart des cas, avec les autorités de certification publiques, les listes de révocation de certificats sont publiées via HTTP. Vérifiez que les ports de sortie et proxy appropriés sont configurés pour que vos serveurs et clients puissent contacter la liste de révocation de certificats. 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.

Dans certains cas, vous devrez peut-être rendre la liste de révocation des certificats publiquement disponible pour l'autorité de certification qui émet vos certificats. Par exemple, si vous déployez la sécurité de domaine, vous devez comprendre que, même si un serveur de transport Edge extrait un certificat appartenant à votre organisation, il valide la chaîne de certificats pour valider le certificat. Par conséquent, la CRL de votre autorité de certification 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 l'autorité de certification qui émet vos certificats.

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

Les serveurs Exchange 2007 s'appuient sur les services HTTP Windows (WinHTTP) sous-jacents pour gérer tout le trafic HTTP et HTTPS. Par exemple, les serveurs de transport Hub et de transport Edge peuvent utiliser HTTP pour accéder à des mises à jour de la fonction anti-courrier indésirable d'Exchange 2007 Standard ou Forefront Security for Exchange Server. Tous les rôles serveur Exchange utilisent WinHTTP pour activer la validation des listes de révocation des certificats.

Pour plus d'informations, consultez la rubrique Procédure de configuration de paramètres de 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 Exchange spécifique, utilisez Certutil.exe pour vérifier la chaîne de certificats pour le certificat de votre serveur. Certutil.exe est un outil de ligne de commande installé dans le cadre des services de certificats des systèmes d'exploitation Windows Server. Pour plus d'informations, consultez la rubrique Test de l'infrastructure à clé publique et configuration de proxy.

Retour au début

Création, importation et activation de certificats

En fonction de vos besoins, il existe différentes manières d'obtenir un certificat installé et opérationnel sur Exchange 2007. Exchange 2007 génère un ensemble de certificats auto-signés pour sécuriser la configuration par défaut. Cette dernière doit être renouvelée régulièrement pour assurer la sécurité du système. Exchange ne génère pas automatiquement de demandes de signature par les autorités de certification. Que vous souhaitiez créer un certificat auto-signé ou une demande de certificat pour une autorité de certification, les deux méthodes utilisent la même cmdlet.

Cette section offre une vue d'ensemble des opérations que vous pouvez exécuter sur les certificats utilisés par Exchange 2007. Consultez cette section si vous ne connaissez pas les cmdlets ExchangeCertificate. Des exemples et procédures spécifiques à l'application sont présentés ultérieurement dans ce document, à l'aide d'un exemple basé sur POP3. Cette section contient également des liens vers de la documentation spécifique à l'application.

Cmdlets liées aux certificats

Dans les versions antérieures d'Exchange Server, les certificats étaient gérés via les services Internet (IIS) et le Gestionnaire de certificats dans la console MMC. Dans Exchange 2007, les cmdlets ExchangeCertificate suivantes et l'environnement de ligne de commande Exchange Management Shell permettent d'exécuter la plupart des tâches de gestion de certificat :

  • New-ExchangeCertificate   Cette cmdlet génère des certificats auto-signés et demandes de certificat pour les autorités de certification.

  • Import-ExchangeCertificate   Cette cmdlet importe les certificats précédemment exportés et importe les fichiers de certificat générés par les autorités de certification.

  • Export-ExchangeCertificate   Cette cmdlet exporte les certificats à des fins de sauvegarde ou pour une utilisation sur plusieurs serveurs.

  • Enable-ExchangeCertificate   Cette cmdlet active des services spécifiques sur un certificat.

  • Get-ExchangeCertificate   Cette cmdlet affiche les attributs d'un certificat.

  • Remove-ExchangeCertificate   Cette cmdlet supprime les certificats d'Exchange Server et du magasin de certificats local.

Pour plus d'informations sur la création de demandes de certificat pour les autorités de certification, consultez la rubrique Création d’un certificat ou demande de certificat pour TLS.

Les sections suivantes présentent de courts exemples permettant de présenter l'utilisation des cmdlets ExchangeCertificate pour exécuter des tâches courantes liées aux certificats. Pour plus d'informations et d'exemples, consultez l'aide relative à la cmdlet ExchangeCertificate sous Cmdlets globales.

Génération de certificats auto-signés

Pour générer un certificat auto-signé à des fins d'utilisation pour le service SMTP pour un serveur dont le nom d'hôte est Server1 et le domaine est fourthcoffee.com, exécutez la commande suivante :

New-ExchangeCertificate -DomainName "server1.fourthcoffee.com", "server1" -Services "SMTP"

Copie de certificats auto-signés

Pour renouveler un certificat auto-signé existant, vous pouvez le copier à l'aide de la commande suivante :

Get-ExchangeCertificate <thumbprint> | New-ExchangeCertificate

L'espace réservé thumbprint correspond à l'empreinte du certificat à renouveler. Vous pouvez également spécifier les services pour le nouveau certificat dans la commande, comme suit :

Get-ExchangeCertificate <thumbprint> | New-ExchangeCertificate -Services SMTP,POP,IMAP

Vous pouvez ensuite activer ce certificat en exécutant la commande suivante :

Enable-ExchangeCertificate <thumbprint>

Création de demandes de certificat et installation de certificats approuvés

L'installation d'un certificat tiers public est plus complexe. Vous devez générer une demande de certificat, importer le certificat émis et tous les certificats d'autorité de certification requis, puis activer le certificat émis pour les utilisations correspondantes.

Cette section fournit un exemple d'activation du service POP3 à des fins d'utilisation de certificats. Dans cet exemple, les clients se connectent au service POP3 en se connectant au nom de domaine complet popserver.fourthcoffee.com.

Demande de certificat

Comme le certificat obtenu provient d'une autorité de certification publique tierce, vous devez commencer par générer une demande de certificat en exécutant la commande suivante :

New-ExchangeCertificate -DomainName popserver.fourthcoffee.com -SubjectName "c=us,o=contoso corp, cn=popserver.fourthcoffee.com" -PrivateKeyExportable:$True -GenerateRequest:$True -Path "C:\CertRequest.req"

Si la demande de certificat est correctement générée, un fichier de demande de certificat (.cer ou .der) est créé à la racine du lecteur système et l'environnement de ligne de commande Exchange Management Shell affiche une empreinte pour la demande.

Notes

Les certificats renvoyés par les fournisseurs prennent en charge différentes extensions pour le fichier de demande de certificat, telles que .der ou .cer. Ces extensions représentent la méthode de codage utilisée pour le fichier de certificat. Par défaut, la demande New-ExchangeCertificate crée un fichier codé en Base64 (.cer). Le paramètre booléen BinaryEncoded permet de créer un fichier .der.

Dans la commande précédente, le paramètre PrivateKeyExportable est défini sur $True de sorte que ce certificat peut être exporté avec la clé privée à des fins d'utilisation sur plusieurs serveurs Exchange auxquels il est possible d'accéder à l'aide du même nom de domaine complet. Par exemple, il est possible de procéder à un équilibrage de la charge de plusieurs serveurs d'accès au client de sorte qu'ils puissent prendre en charge les connexions POP3.

Notes

Le paramètre PrivateKeyExportable est facultatif. Vous ne devez le spécifier que lorsque vous générez des demandes de certificat pour les autorités de certification approuvées. En définissant le paramètre PrivateKeyExportable sur $True, vous pouvez déplacer et archiver le certificat et les clés associées. Cette procédure n'est pas nécessaire pour les certificats auto-signés.

La commande précédente spécifie également le paramètre Subjectname comme nom X.500. La plupart des autorités de certification tierces exigent la spécification d'un nom X.500 valide pour le paramètre Subjectname du certificat. La plupart des autorités de certification requièrent que l'organisation répertoriée dans le champ organizationName (o=) possède au moins le nom de domaine qui apparaît dans le champ commonName (cn=) du serveur Web.

Une fois la demande effectuée, vous pouvez envoyer le fichier de demande à un fournisseur de certificats afin d'obtenir un certificat.

Notes

La cmdlet Get-ExchangeCertificate renvoie les certificats, y compris ceux dont les demandes sont en attente. Pour différencier les deux types de certificats, les demandes contiennent un attribut CertificateRequest qui affiche la sortie stockée dans le fichier de demande de certificat. Cette sortie peut être utile si vous supprimez accidentellement le fichier de demande de certificat ou générez la demande sans le paramètre. Les données CertificateRequest sont codées en base64 et peuvent être copiées vers un fichier et envoyées à votre autorité de certification à des fins de demande de certificat.

Importation d'un certificat

Une fois le certificat renvoyé par une autorité de certification, vous devez l'importer vers le serveur Exchange. Pour importer un certificat dont la demande a été générée à l'aide de la cmdlet New-ExchangeCertificate, exécutez la commande suivante :

Import-ExchangeCertificate -Path "C:\CertificateFile.cer"

Si l'importation du certificat a réussi, la commande renvoie l'empreinte du certificat que vous pouvez utiliser pour activer des services spécifiques.

importantImportant :
Vous devez installer le certificat sur l'ordinateur à partir duquel la demande a été générée. En outre, pour importer des certificats Exchange, n'utilisez pas le Gestionnaire de certificats de la console MMC.

Activation d'un certificat

Activer un certificat vous permet de spécifier quels services peuvent l'utiliser. La commande suivante active le certificat émis pour le service POP3 :

Enable-ExchangeCertificate <thumprint> -Services:"POP"

Vous pouvez importer et activer un certificat simultanément en exécutant la commande suivante :

Import-ExchangeCertificate -Path "C:\CertificateFile.cer" | Enable-ExchangeCertificate -Services:"POP"

Validation de l'installation d'un certificat

Pour confirmer l'exécution des étapes requises et l'installation et le fonctionnement du certificat, exécutez la commande suivante :

Get- ExchangeCertificate <thumbprint> | fl *

Notes

Si votre ordinateur exécute Exchange Server 2007 SP 1 ou versions ultérieures, omettez l'astérisque (*) sur l'argument de commande.

La sortie de la commande renvoie des données identiques à ce qui suit :

AccessRules        : {System.Security.AccessControl.CryptoKeyAccessRule, System.Security.AccessControl.CryptoKeyAccessRule,System.Security.AccessControl.CryptoKeyAccessRule}
CertificateDomains : {popserver.fourthcoffee.com, fourthcoffee.com}
HasPrivateKey      : True
IsSelfSigned       : False
Issuer             : CN=3rdPartyCAExample.com
NotAfter           : 8/7/2008 10:04:02 AM
NotBefore          : 8/7/2007 10:04:02 AM
PublicKeySize      : 2048
RootCAType         : ThirdParty
SerialNumber       : 83FAE8B2398F2A9E44485CBA85D548DF
Services           : POP
Status             : Valid
Subject            : C=us,o=contoso corp, CN=fourthcoffee.com 
Thumbprint         : 257C327A164ED8A6FCDAFCA7789D29B60369DCA7

Inspectez la sortie de la commande pour valider les informations suivantes :

  • Les noms de domaine dont la présence est requise sont répertoriés dans le champ CertificateDomains.

  • La propriété HasPrivateKey est définie sur True.

  • La propriété RootCAType est définie correctement. Pour plus d'informations sur la propriété RootCAType, consultez la section Propriétés de certificat ci-avant dans le document.

  • Les services requis sont activés pour le certificat.

  • L'état est défini sur Valid.

Services de certificats

Il est possible d'activer des services, tels que POP, IMAP, les services IIS et SMTP sur un certificat. Les services ne correspondent pas à des champs du certificat en tant que tel. Il s'agit de propriétés de métadonnées des certificats. Vous pouvez donc les modifier sans invalider le certificat.

Lorsque des services sont activés, d'autres composants subissent des modifications de configuration, tels que la métabase IIS, le système de fichiers ou les paramètres IMAP4 et POP3. Cette section présente les modifications de configuration qui se produisent lorsque vous activez un service donné en exécutant la cmdlet Enable-ExchangeCertificate.

POP et IMAP

Lorsque POP et IMAP sont ajoutés en tant que services supplémentaires à un certificat, l'attribut x509CertificateName de l'objet POPSettings ou IMAPSettings est mis à jour afin d'inclure le domaine dans l'objet du certificat.

Par exemple, pour vérifier que l'objet POPSettings a été mis à jour, exécutez la commande suivante :

Get-POPSettings | fl *

Notes

Si votre ordinateur exécute Exchange Server 2007 SP 1 ou versions ultérieures, omettez l'astérisque (*) sur l'argument de commande.

Services Internet (IIS)

Lorsque les services Internet (IIS) sont activés, le site Web IIS par défaut est mis à jour afin d'utiliser ce certificat spécifique.

Vous pouvez activer un certificat pour les services Internet (IIS) à l'aide de la cmdlet Enable-ExchangeCertificate, uniquement pour le site Web IIS par défaut. Si vous hébergez Outlook Web Access ou le service de découverte automatique sur des sites Web autres que le site Web IIS par défaut, vous devez utiliser le Gestionnaire des services Internet (IIS) pour associer un certificat spécifique à ces sites Web.

SMTP

Lorsque le service SMTP est activé sur un certificat, le compte de service réseau obtient un accès en lecture au fichier de clé privée approprié dans le répertoire Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys. Le service de transport Microsoft Exchange peut ainsi accéder à la clé privée et l'utiliser pour déchiffrer des messages sécurisés par TLS.

Service de messagerie unifiée Microsoft Exchange

Lorsque le service de messagerie unifiée Microsoft Exchange est activé sur un certificat, la propriété de ce dernier est mise à jour afin d'inclure la messagerie unifiée. Ce certificat est utilisé si les conditions suivantes sont vérifiées :

  • Le rôle serveur de messagerie unifiée est installé sur l'ordinateur.

  • Le certificat contient le nom de domaine complet physique de l'ordinateur local dans le champ de certificat CertificateDomains.

Retour au début

Sélection de certificats

La sélection de certificats est un processus que les composants Exchange exécutent pour déterminer quels certificats doivent être utilisés pour une connexion entrante. SMTP, STARTTLS, POP3 et IMAP4 exécutent un processus de sélection identique pour déterminer quels certificats doivent être utilisés pour une session particulière. Ce processus est relativement déterministe. Toutefois, il peut porter à confusion, notamment lorsque plusieurs certificats sont installés sur l'ordinateur.

Cette section décrit le processus de sélection de certification pour SMTP STARTTLS, SMTP X-AnonymousTLS, POP3 et IMAP4. Pour plus d'informations sur la sélection de certificats spécifiques au transport, consultez la rubrique Sélection d'un certificat TLS SMTP.

SMTP STARTTLS

STARTTLS est le verbe SMTP permettant d'ouvrir une session TLS sécurisée. STARTTLS n'est signalé par Exchange que si un certificat valide existe sur l'ordinateur exécutant Exchange.

Pour signaler ou utiliser STARTTLS, Exchange sélectionne un certificat basé sur le nom de domaine complet et une valeur correspondante dans le champ CertificateDomains d'un certificat. Le nom de domaine complet est basé sur les informations suivantes :

  • STARTTLS sortant   Le certificat est sélectionné sur la base de la valeur de nom de domaine complet sur un connecteur d'envoi.

  • STARTTLS entrant   Le certificat est sélectionné sur la base de la valeur de nom de domaine complet sur un connecteur de réception.

    Notes

    Pour STARTTLS sortant et STARTTLS entrant, si le nom de domaine complet du connecteur n'est pas spécifié, le nom de domaine complet physique du serveur Exchange est utilisé pour la correspondance.

Une fois le nom de domaine complet déterminé, Exchange recherche tous les certificats valides dans le magasin de certificats Personnel sur l'ordinateur hôte. Un certificat est valide pour l'usage de TLS s'il satisfait aux critères suivants :

  • Le champ Utilisation avancée de la clé contient l'identificateur d'objet Authentification du serveur (également appelé OID) ou une valeur nulle.

  • L'extension de certificat d'infrastructure à clé publique contient une clé RSA avec un minimum de 1024 bits.

  • Le certificat valide la chaîne de certificats jusqu'à une racine approuvée ou est auto-signé.

  • Le certificat et la chaîne de certificats transmettent le vérification de révocation.

  • La clé privée est présente et disponible.

  • La clé privée n'est pas conservée sur un périphérique amovible.

  • La clé privée n'est pas protégée par mot de passe.

Si plusieurs certificats valides sont trouvés, Exchange en sélectionne un sur la base des critères suivants :

  • Valeur du champ NotBefore   Exchange sélectionne le certificat valide le plus récent.

  • Certificats émis par une autorité de certification approuvée et certificats auto-signés   Exchange sélectionne les certificats émis par une autorité de certification approuvée plutôt que des certificats auto-signés.

Le plus souvent, Exchange sélectionne un certificat émis par une autorité de certification approuvée plutôt qu'un certificat auto-signé, quel que soit l'âge du certificat. À défaut de certificat valide, STARTTLS n'est pas signalé.

SMTP X-AnonymousTLS

X-AnonymousTLS facilite la sécurisation de la communication entre deux serveurs de transport Hub et entre des serveurs de transport Hub et des serveurs de transport Edge. Dans Exchange 2007 SP1, le processus de sélection de certificats a été simplifié de façon à ce que, si aucun certificat n'est trouvé, une clé de chiffrement temporaire est générée pour la session.

Exchange recherche un certificat de transport interne. Si Exchange ne trouve aucun certificat de transport interne, il recherche un certificat valide émis par une autorité de certification.

C'est pourquoi, pour la communication entre serveurs de transport Hub où le protocole Kerberos est utilisé pour l'authentification, l'absence de certificat de transport interne valide n'entraîne pas l'échec de la session SMTP. La session SMTP est chiffrée à l'aide de la clé de chiffrement temporaire. Dans ce cas, un événement est journalisé et vous devez créer un certificat de transport interne en exécutant la cmdlet New-ExchangeCertificate sans argument sur l'ordinateur générant l'événement.

Pour la communication entre serveurs de transport Hub et Edge, où le serveur de transport Edge est abonné à l'organisation, si aucun certificat de transport interne valide n'est trouvé, la session échoue et une erreur est consignée. Dans ce cas, vous devez exécuter la cmdlet New-ExchangeCertificate sans argument sur l'ordinateur qui génère l'événement, puis exécuter de nouveau le service Microsoft Exchange EdgeSync.

POP3 et IMAP4

Comme dans le processus de sélection de certificats pour SMTP STARTTLS, dans le processus pour POP3 et IMAP4, Exchange doit sélectionner un nom de domaine complet et trouver un certificat basé sur une valeur correspondante dans le champ CertificateDomains. Le nom de domaine complet est choisi sur la base de l'attribut X509CertificateName dans les paramètres de service POP3 ou IMAP4. Vous pouvez afficher l'attribut X509CertificateName en exécutant la cmdlet Get-POPSettings ou la cmdlet Get-IMAPSettings. Pour plus d'informations, consultez les rubriques Get-POPSettings et Get-IMAPSettings.

Le processus de sélection pour POP3 et IMAP4 dans Exchange 2007 SP1 est identique au processus pour SMTP STARTTLS.

Notes

Dans Exchange 2007 RTM, il y a deux exceptions majeures dans les processus de sélection de certificats pour POP3 et IMAP4. Les certificats émis par un autorité de certification approuvée ne sont pas préférés aux certificats auto-signés. Exchange 2007 sélectionne plutôt le certificat le plus récent. De même, dans Exchange 2007 RTM, POP3 et IMAP4 ne prennent pas en charge les domaines génériques dans des certificats. Cela signifie que si l'attribut X509CertificateName est défini sur mail.fourthcoffee.com pour les paramètres POP3 ou IMAP4, Exchange 2007 ne prend pas en charge un certificat ne contenant que *.fourthcoffee.com comme domaine de certificat.

Messagerie unifiée

Si le service de messagerie unifiée Microsoft Exchange est démarré en mode sécurisé, il interroge le magasin de certificats Personnel local afin de rechercher un certificat valide à utiliser pour que TLS active le chiffrement. Le service de messagerie unifiée Microsoft Exchange commence par rechercher un certificat valide émis par une infrastructure à clé publique ou une autorité de certification publique. À défaut de certificat approprié, il recherche un certificat auto-signé. À défaut de certificat d'infrastructure à clé publique, public ou auto-signé, le service de messagerie unifiée Microsoft Exchange crée un certificat auto-signé à utiliser pour démarrer en mode sécurisé. Si le serveur de messagerie unifiée démarre en mode non sécurisé, aucun certificat n'est nécessaire.

Tous les détails du certificat utilisé pour démarrer en mode sécurisé sont consignés chaque fois qu'un certificat est utilisé ou si le certificat a changé. Les détails consignés sont les suivants :

  • Nom d'émetteur

  • Numéro de série

  • Empreinte

L'empreinte numérique est l'algorithme de hachage sécurisé. Il est possible de l'utiliser pour identifier de façon unique le certificat utilisé. Vous pouvez exporter le certificat utilisé par le service de messagerie unifiée Microsoft Exchange pour démarrer en mode sécurisé depuis le magasin de certificats local, puis importer ce certificat sur les passerelles IP de messagerie unifiée et les IP PBX sur votre réseau vers le magasin de certificats approuvés.

Une fois un certificat approprié trouvé et utilisé, le service de messagerie unifiée Microsoft Exchange consigne un événement un mois avant l'expiration du certificat utilisé. Si vous n'apportez pas de modification au certificat pendant ce temps, le service de messagerie unifiée Microsoft Exchange consigne un événement quotidiennement jusqu'à ce que le certificat expire et quotidiennement après expiration du certificat.

Lorsque le serveur de messagerie unifiée recherche un certificat à utiliser afin que Mutual TLS établisse un canal chiffré, il recherche dans le magasin de certificats racines approuvés. S'il y a plusieurs certificats valides provenant de différents émetteurs, le serveur de messagerie unifiée sélectionne le certificat valide dont la période restante avant expiration est la plus longue. S'il y a plusieurs certificats, le serveur de messagerie unifiée les sélectionne en fonction de l'émetteur et de la date d'expiration. Le serveur de messagerie unifiée recherche un certificat valide dans l'ordre de préférence suivant :

  1. infrastructure à clé publique ou certificat public dont la période avant expiration est la plus longue ;

  2. infrastructure à clé publique ou certificat commercial dont la période avant expiration est la plus courte ;

  3. certificat auto-signé dont la période avant expiration est la plus longue ;

  4. certificat auto-signé dont la période avant expiration est la plus courte.

Retour au début

Pour plus d'informations

Cette rubrique contient des références aux documents suivants :

Retour au début