Création d’un certificat ou demande de certificat pour TLS

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

Dernière rubrique modifiée : 2011-11-04

Cette rubrique décrit la création des certificats de protocole TLS (Transport Layer Security) X.509 ou une demande de certificat en utilisant les cmdlets ExchangeCertificate dans l'environnement de ligne de commande Exchange Management Shell.

Important :
Avant de lire cette rubrique, assurez-vous de disposer de connaissances suffisantes sur l'utilisation générale des certificats dans Microsoft Exchange Server 2007. Consultez la rubrique Utilisation de certificats dans un serveur Exchange 2007.

En termes de chiffrement, le certificat et les clés privées relatives générés par la cmdlet New-ExchangeCertificate sont les clés TLS. La cmdlet New-ExchangeCertificate permet la spécification de métadonnées sur le certificat afin que les différents services utilisent le même certificat et la même clé privée. Avant de créer les certificats ou les demandes de certificat pour les services Exchange utilisant TLS, la compréhension des métadonnées utilisées par les certificats pour les services de SSL et de TLS est nécessaire. Cette métadonnée est appelée « champs » dans le certificat obtenu.

Pour afficher les champs des certificats d’ordinateur sur un ordinateur donné, vous pouvez utiliser la cmdlet Get-ExchangeCertificate dans l'environnement de ligne de commande Exchange Management Shell. Vous pouvez également utiliser le composant logiciel enfichable MMC (Microsoft Management Console) Gestionnaire de certificats. Pour plus d'informations sur l'utilisation du composant logiciel enfichable Gestionnaire de certificats, consultez la rubrique Procédure d'ajout du Gestionnaire de certificats à Microsoft Management Console (MMC).

Présentation des champs utilisés par les certificats pour les services TLS.

Si vous utilisez la cmdlet New-ExchangeCertificate pour générer une demande de certificat à partir d’un tiers ou d’une autre autorité de certification d’infrastructure à clé publique (PKI), assurez-vous que la validation des champs de certificat et du format de certificat requis par l' autorité de certification est effectuée.

Cette section décrit les champs de certificat les plus importants et fournit certaines meilleures pratiques pour la génération des certificats et des demandes de certificat.

Nom du sujet

Le nom du sujet d’un certificat TLS est le champ utilisé par les services prenant en charge DNS. Le nom du sujet lie un certificat à un serveur particulier ou à un nom de domaine.

Un nom de sujet est un nom unique X.500 comprenant un ou plusieurs noms uniques relatifs (également appelés RDN). Le tableau suivant répertorie les noms uniques relatifs, fréquemment utilisés pour l’identification des organisations ou des entités de serveur.

Les codes de région/pays sont les codes ISO 3166-1. Pour plus d’informations, consultez les noms des pays anglophones et les codes des éléments.

Le composant de domaine et le pays/la région s’excluent mutuellement par convention. Il est recommandé de référencer le nom par pays/région ou de référencer le nom par DNS (Domain Name System). En outre, prenez en considération la taille maximale du composant de domaine (255 caractères) est la somme de toutes les valeurs du composant de domaine.

Important :
Bien que les certificats puissent avoir plusieurs noms de champ communs, certains services sont mis en oeuvre sur l’hypothèse qu’il n’existe qu’un seul nom commun. Par conséquent, plusieurs noms communs peuvent causer des problèmes d’interopérabilité. Il est recommandé que le certificat ou la demande de certificat que vous créez ne contienne qu’un nom commun.

Implémentation des noms uniques relatifs

Les noms du sujet sont représentés dans la cmdlet New-ExchangeCertificate comme paramètre unique comportant une série de noms séparés par des virgules. Chaque nom est identifié par l’abréviation du nom unique relatif. Par exemple, le nom du sujet suivant représente un pays/une région = US, Organisation = Contoso Corp, et nom commun = mail1.contoso.com :

-SubjectName "C=US o=contoso corp, CN=mail1.contoso.com"

D'autres exemples de noms de sujet capables de représenter le même serveur sont fournis dans les exemples suivants :

-SubjectName  "O=contoso corp, CN=mail1.contoso.com"
-SubjectName "DC=contoso, DC=com, CN=mail1.contoso.com"
-SubjectName "DC= contoso, DC=com, O=contoso corp, CN=mail1.contoso.com"

Si vous avez un nom DNS enregistré que vous utilisez pour envoyer un courrier SMTP, il est recommandé d’utiliser la convention du composant de domaine et le nom DNS pour le nom du certificat, tel que DC=contoso, DC=com, CN=mail1.contoso.com.

Toutefois, lors de la génération d’une demande de certificat pour une autorité de certification, la compréhension des exigences du champ Nom du sujet de l’autorité de certification et vos exigences uniques PKI est nécessaire. Dans certains cas, l’utilisation du code (« C ») de pays/région peut être requise. Si c’est le cas, il est recommandé d’enregistrer votre nom unique relatif à une autorité d’enregistrement X.500.

Noms d’objet international

Pour les noms de l’objet contenant des caractères non-ASCII, entrez le paramètre SubjectName comme un nom unique entre des guillemets, de la manière suivante :

-SubjectName "C=ES,O=Diversión de Bicicleta,CN=mail1. DiversiondeBicicleta.com"

Noms de l’objet et noms de domaine

Par convention, un nom commun peut contenir un nom de domaine complet (FQDN). Bien que cette pratique soit répandue et recommandée, la compréhension des deux questions ci-après est nécessaire.

Premièrement, la taille maximale du champ du nom commun est de 64 caractères. Moins de caractères comparé à la taille maximale d’un FQDN. Par conséquent, pour un FQDN avec plus de 64 caractères, le nom de domaine doit être placé dans Autre nom de l’objet. Le paramètre DomainName est le paramètre qui mappe l’Autre nom de l’objet sur le certificat obtenu.

Deuxièmement, le FQDN est restreint à un sous-ensemble de jeu de caractères ASCII. Toutefois, le nom commun (CN) prend en charge Unicode. Par conséquent, un certificat valide peut être créé avec un CN similaire à un nom du DNS mais qui est un nom du DNS non valide. Le logiciel à la recherche d’un FQDN dans un certificat CN renverra des résultats corrects si le CN contient des caractères non-ASCII. Par exemple, si un certificat est créé avec un Nom de l’objet, où CN=mail.mïcrosoft.com, le nom sera ignoré comme FQDN car le nom contient un caractère Unicode (le caractère ï avec la diacritique (x00ef)). À l’oeil nu, le CN d’Unicode peut facilement être confondu avec un FQDN due la différence mineure entre le caractère ï et la diacritique (x00ef) et le i d’ASCII (x0069). La validité du FQDN de l’objet CN n’est pas requise ou appliquée à la tâche du certificat d’Exchange. Par défaut, ceci signifie que la cmdlet inclut le FQDN du serveur comme le CN par défaut.

Certificat de noms de domaine

Pour le TLS, les certificats doivent avoir les noms du DNS car le TLS est un protocole basé sur un DNS. Les clients vérifient le nom du DNS du serveur auquel ils se connectent avec le nom du DNS auquel ils souhaitent se connecter. C’est le cas des navigateurs du Web qui se connectent au site Web sur les HTTPS et pour les serveurs SMTP qui transmettent les messages électroniques à travers Internet ou l’intranet.

Un serveur unique peut prendre en charge plusieurs noms du DNS pour les raisons ci-après :

• Un serveur SMTP prend en charge plusieurs domaines acceptés

• Un client peut accéder à un serveur de messagerie électronique par le nom de serveur, par le nom de domaine, par un nom local de FQDN ou par un nom d’équilibrage.

Lorsqu’une connexion de TLS est établie, si le client trouve le nom qu’il cherche, le client ignore les autres noms dans le certificat. Plusieurs noms de domaine et de serveur peuvent être ajoutés dans le champ Autre nom de l’objet d’un certificat TLS. Un certificat contenant plusieurs autres noms de l’objet peut être créé en utilisant le paramètre DomainName de la cmdlet New-ExchangeCertificate. Le paramètre DomainName est à valeurs multiples afin d’accepter plusieurs noms.

Les certificats peuvent contenir zéro, un, ou plusieurs noms du DNS dans l’extension du certificat autre nom de l’objet (SubjectAltName). Les noms du DNS dans l’extension SubjectAltName correspondent exactement aux restrictions d’un nom du DNS. Ils ne doivent pas excéder 255 caractères et doivent se composer des éléments A-Z, a-z, 0-9 et un tiret (-).

Logique de correspondance de nom pour la fonctionnalité de sécurité de domaine

La logique de correspondance de nom de certificat pour la fonctionnalité de sécurité du domaine vérifie si un nom de domaine dans le certificat reçu correspond au nom de domaine lors de l'envoi de messages à ce domaine. À titre d'exemple, considérez le nom de domaine complet du domaine de destinataire, woodgrovebank.com. La logique de correspondance de nom de certificat recherche parmi tous les noms DNS dans les certificats et, tant qu'un nom DNS correspond, le certificat est vérifié comme correspondance pour le domaine spécifié.

Dans cet exemple, la logique de correspondance de nom de certificat accepte un certificat avec une correspondance de domaine exacte, telle que woodgrovebank.com. Elle prend également en charge l'utilisation de noms de domaine en caractères génériques dans les certificats, de façon à ce qu'un certificat dont le nom DNS est « *.woodgrovebank.com » soit accepté comme correspondance. Pour plus d'informations sur les noms de domaine en caractères génériques, consultez la section « Noms de domaine en caractères génériques » plus loin dans cette rubrique.

La logique de correspondance de nom de certificat recherche également dans les DNS à une profondeur d'un nœud. C'est pourquoi mail1.woodgrovebank.com est également accepté comme correspondance de woodgrovebank.com. En revanche, les noms DNS d'une profondeur supérieure à deux nœuds ne sont pas acceptés. C'est pourquoi, mail1.us.woodgrovebank.com, par exemple, ne serait pas accepté comme correspondance pour woodgrovebank.com.

Pour plus d'informations sur la manière dont Exchange sélectionne les certificats, consultez la rubrique Sélection d'un certificat TLS SMTP.

Meilleures pratiques pour les noms de domaine du protocole SMTP Internet

Lors de la création d’un certificat ou d’une demande de certificat pour un serveur de transport Edge exécutant le SMTP TLS sur Internet, l’ensemble des noms de domaine à inclure dans la demande sont comme suit :

• Nom de domaine complet Internet qualifié du serveur   Ceci peut être différent du FQDN interne utilisé entre les serveurs de transport Edge et les serveurs de transport Hub et doit correspondre à un répertoire publié sur le serveur DNS d’Internet (publique). Le nom doit être entré comme un CN dans le paramètre SubjectName de la cmdlet New-ExchangeCertificate.

• Noms des domaines acceptés de l’organisation   Le paramètre IncludeAcceptedDomain de la cmdlet New-ExchangeCertificate permet de renseigner l'autre nom du sujet pour le certificat obtenu.

• Le FQDN pour le connecteur si non abordé par l’une des rubriques précédentes   Utilisez le paramètre DomainName de la cmdletNew-ExchangeCertificate afin de remplir l’autre nom de l’objet pour le certificat obtenu.

Meilleures pratiques pour les noms de domaine pour un serveur d’accès au client

Pendant la création d’un certificat ou d’une demande de certificat pour un serveur d’accès au client, l’ensemble de noms de domaine à inclure dans la demande sont comme suit :

• Nom local ou NetBIOS du serveur, par exemple, owa1

• Tous les noms de domaine accepté de l‘organisation, par exemple, contoso.com

• Nom de domaine complet du serveur, par exemple, owa1.contoso.com

• Nom de domaine de découverte automatique pour le domaine, par exemple, Autodiscover.contoso.com

• Identité d’équilibrage de charge du serveur (le cas échéant), par exemple, owa.contoso.com

Noms de domaine des caractères génériques

Les noms de domaine des caractères génériques sont un type spécial du nom de domaine représentant plusieurs domaines secondaires. Les noms de domaine génériques peuvent simplifier les certificats parce qu’un nom de domaine générique unique représente tous les domaines secondaires pour ce domaine. Ils sont représentés par un caractère astérisque ( * ) au noeud du DNS. Par exemple, *.contoso.com représente contoso.com et tous les sous-domaines pour contoso.com. Lorsque vous utilisez un caractère générique pour créer un certificat ou une demande de certificat pour tous les domaines acceptés, la demande peut être considérablement simplifiée.

Duplication d’un certificat existant

Exchange 2007 crée un certificat auto-signé lors de l’installation utilisant tous les noms de serveur et domaine connus par Exchange au moment de l’installation. Ces certificats sont valides pendant 12 mois. Dans certains cas, il est raisonnable de dupliquer ces certificats si l’objet et les autres noms d’objet peuvent être utilisés pour les autres ordinateurs. Seules les métadonnées du certificat et non les ensembles de clés sont dupliqués.

Pour exécuter les cmdlets suivantes 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 dupliquer un nouveau certificat à partir d’un certificat existant, commencez par identifier le certificat actuel pour le domaine en exécutant la commande suivante :

Get-ExchangeCertificate -DomainName mail1.contoso.com

Où mail1.contoso.com est le nom du serveur ou le FQDN à partir duquel vous voulez créer un certificat dupliqué.

Le premier certificat répertorié dans la sortie est le certificat de SMTP TLS par défaut pour le serveur.

Pour copier le certificat, exécutez la commande suivante :

Get-ExchangeCertificate -Thumbprint c4248cd7065c87cb942d60f7293feb7d533a4afc | New-ExchangeCertificate

L’emplacement de la valeur de Thumbprint originaire du premier certificat répertorié dans la sortie pour Get-ExchangeCertificate.

Cette commande extrait les noms à partir du certificat existant identifié par l’empreinte et les utilise dans le nouveau certificat auto-signé.

Génération des demandes pour les services de certificat de tiers

Si une autorité de certification est utilisé pour générer des certificats, une demande de certificat doit être fournie selon les exigences de l

Pour générer une demande de certificat, la cmdlet New-ExchangeCertificate peut être utilisée. Pour générer une demande de certificat, utilisez le paramètre GenerateRequest conjointement avec le paramètre Path pour définir l’emplacement où le fichier de demande sera créé. Le fichier obtenu sera un fichier de demande (.req) PKCS #10. PKCS #10 est la norme de syntaxe de demande de certification spécifiée par RFC 2314 (http://www.ietf.org/rfc/rfc2314.txt).

Les exemples suivants illustrent quelques demandes de certificats classiques.

Le premier exemple génère une demande de certificat pour le serveur du Contoso, mail1. Le CN de l’objet contient le FQDN du serveur et l’autre nom de l’objet contient tous les domaines acceptés pour Contoso.

New-ExchangeCertificate -GenerateRequest -SubjectName "c=us, o=contoso corp, cn=mail1.contoso.com" -IncludeAcceptedDomains -Path c:\certificates\mail1.contoso.com.req

Le second exemple génère une demande de certificat pour le serveur Contoso, mail1. Contoso a un connecteur d’envoi sur chaque serveur de transport Edge ayant un FQDN du mail.contoso.com.

New-ExchangeCertificate -GenerateRequest -SubjectName "C=US, O=contoso corp, CN=mail1.contoso.com" -IncludeAcceptedDomains -DomainName mail.contoso.com -Path c:\certificates\mail1.contoso.com.req

Le troisième exemple crée une demande de certificat à partir du certificat Contoso.com existant.

Get-ExchangeCertificate -Thumbprint c4248cd7065c87cb942d60f7293feb7d533a4afc | New-ExchangeCertificate -GenerateRequest -SubjectName "C=us, O=contoso corp, CN=mail1.contoso.com" -Path c:\ certificates\mail1.contoso.com.req

Le dernier exemple illustre comment créer une demande de certificat avec un caractère générique pour tous les domaines secondaires de Contoso.com.

New-ExchangeCertificate -GenerateRequest -SubjectName "C=us, O=contoso corp, CN=mail1.contoso.com" -DomainName *.contoso.com -Path c:\ certificates\mail1.contoso.com.req

Pour d'autres exemples, consultez le billet de l'équipe Microsoft Exchange sur les leçons apprises : Génération d'un certificat avec un tiers.

Installation des certificats émis par des demandes de certificat

Après l’envoi de la demande de certificat à une autorité de certification, celle-ci émet un certificat ou une chaîne de certificats. Dans les deux cas, les certificats sont délivrés comme des fichiers à installer obligatoirement avec la cmdlet Import-ExchangeCertificate.

Important :
Il est déconseillé d’utiliser le composant logiciel enfichable du gestionnaire de certificat pour importer les certificats pour tout service sur un serveur d’Exchange. L’utilisation du composant logiciel enfichable du gestionnaire de certificat pour importer les certificats sur les serveurs d’Exchange échouera. Par conséquent, les services du certificat d’Exchange ne fonctionneront pas.

Les exemples suivants illustrent comment importer un certificat pour le TLS du protocole SMTP

Import-ExchangeCertificate -Path c:\certificates\newcert.cer | Enable-ExchangeCertificate -Services SMTP

L'exemple suivant illustre comment importer un certificat et l’activer pour un serveur d’accès au client qui prend en charge les clients POP3 (Post Office Protocol version 3).

Import-ExchangeCertificate -Path c:\certificates\newcert.p7b | Enable-ExchangeCertificate -Services IIS,POP

Pour plus d'informations

Pour plus d'informations sur les autorités de certification qui régissent des sites Web spécifiques à Exchange, consultez l'article 929395 de la Base de connaissances Microsoft sur les partenaires de certification des communications unifiées pour Exchange 2007 et Communications Server 2007.

Pour plus d'informations sur les technologies et les concepts liés à la cryptographie et aux certificats, consultez les publications suivantes :

• Housley, Russ et Tim Polk. Planification de l'infrastructure à clé publique (PKI) : Guide des meilleures pratiques pour le déploiement d’une infrastructure à clé publique (Best Practices Guide for Deploying Public Key Infrastructure) New York : John Wiley & Son, Inc., 2001.

• Adams, Carlisle et Steve Lloyd. Cryptographie Appliquée : Algorithmes, protocoles et codes source en langage C, 2e Edition. (Applied Cryptography : Protocols, Algorithms, and Source Code in C, 2nd Edition). New York : John Wiley & Son, Inc., 1996.

• Meilleures pratiques pour l'implémentation d'une infrastructure à clé publique Microsoft Windows Server 2003