Présentation des certificats TLS

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

Dernière rubrique modifiée : 2016-11-28

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 spécifique, vous pouvez utiliser la cmdlet Get-ExchangeCertificate de l’environnement de ligne de commande Exchange Management Shell. Vous pouvez également utiliser le composant logiciel enfichable MMC (Microsoft Management Console) Gestionnaire de certificats.

Souhaitez-vous rechercher des tâches de gestion relatives aux certificats TLS ? Voir Certificats.

Contenu de cette rubrique

Champs utilisés par les certificats pour les services TLS.

Sélection de certificats

Création de certificats TLS

Références

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, voir noms de pays anglais et éléments de code.

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 œuvre en supposant 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.

Spécification des noms uniques relatifs

Lors de la création de demandes de certificats à l’aide de la cmdlet New-ExchangeCertificate, les noms d’objet sont représentés 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 utilisez un nom DNS enregistré 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 tel est le cas, il est recommandé d’enregistrer votre nom unique relatif auprès d’une autorité d’enregistrement X.500.

Noms d’objet international

Pour les noms d’objet contenant des caractères non-ASCII, entrez le paramètre SubjectName comme un nom unique entre 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, gardez à l’esprit les deux problèmes suivants si vous adoptez cette approche :

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 contenant 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’œil nu, le CN d’Unicode peut être facilement 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 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 s’appuie sur la résolution 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 HTTPS et des serveurs SMTP qui transmettent les messages électroniques via 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 d’objet peut être créé à l’aide du 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.

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.

• Tous les noms de domaines acceptés de l’organisation   Le paramètre IncludeAcceptedDomains de la cmdlet New-ExchangeCertificate permet de renseigner l’autre nom de l’objet pour le certificat obtenu.

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

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 nœud 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.

Sélection de certificats

Exchange adopte des processus de sélection de certificats différents selon le type de connexion SMTP.

Lorsque les serveurs de transport Hub communiquent les uns avec les autres ou avec les serveurs de transport Edge de votre organisation, des certificats TLS anonymes sont utilisés. Pour plus d’informations, consultez les rubriques Sélection de certificats TLS anonymes entrants et Sélection de certificats TLS anonymes sortants.

Lorsqu’un hôte ou un client SMTP se connecte aux serveurs de transport Edge ou Hub, le processus de sélection du certificat STARTTLS est utilisé. Pour plus d’informations, consultez la rubrique Sélection de certificats STARTTLS entrants.

Création de certificats TLS

Exchange 2010 crée un certificat auto-signé lors de l’installation. Ce dernier utilise tous les noms de serveur et de domaine connus d’Exchange au moment de l’installation. Vous pouvez dupliquer ce certificat afin de l’utiliser sur des serveurs supplémentaires. Vous pouvez également remplacer ce certificat par des certificats émis par une autorité de certification tierce. Les rubriques suivantes fournissent des instructions détaillées pour chaque tâche :

• Générer une demande pour les services de certificat de tiers

• Installer des certificats émis pour des demandes de certificat

• Dupliquer un certificat existant

Références

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

• PKI Windows Server 2008 et sécurité des certificats

• 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.

• Schneier, Bruce. 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.

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