Certificats numériques et chiffrement dans Exchange Server

Les certificats de chiffrement et numériques représentent des considérations importantes dans n'importe quelle organisation. Par défaut, Exchange Server est configuré pour utiliser le TLS (Transport Layer Security) pour chiffrer les communications entre les serveurs Exchange internes et entre les services Exchange sur le serveur local. Mais, les administrateurs Exchange doivent prendre en considération leurs besoins en matière de chiffrement pour les communications avec les clients internes et externes (ordinateurs et appareils mobiles), et les serveurs de messagerie externes.

Notes

Exchange Server 2019 inclut des modifications importantes pour améliorer la sécurité des connexions client et serveur. La configuration par défaut pour le chiffrement active uniquement TLS 1.2 et désactive la prise en charge des algorithmes plus anciens (en l'occurrence, DES, 3DES, RC2, RC4 et MD5). Elle configure également les algorithmes d’échange de clés à courbe elliptique avec une priorité sur les algorithmes de courbe non elliptique. Dans Exchange Server 2016 et les versions ultérieures, tous les paramètres de chiffrement sont hérités de la configuration spécifiée dans le système d’exploitation. Pour plus d'informations, consultez la rubrique Déploiements hybrides TLS Guidance.

Cette rubrique décrit les différents types de certificats disponibles, la configuration par défaut des certificats dans Exchange et les recommandations pour les certificats supplémentaires que vous devez utiliser avec Exchange.

Pour les procédures requises pour les certificats dans Exchange Server, voir Procédures de certificat dans Exchange Server.

Vue d'ensemble des certificats numériques

Les certificats numériques sont des fichiers électroniques fonctionnant comme les mots de passe en ligne permettant de vérifier l'identité d'un utilisateur ou d'un ordinateur. Ils sont utilisés pour créer le canal chiffré utilisé pour les communications clientes. Un certificat est un relevé numérique émis par une autorité de certification (CA) qui authentifie l'identité du titulaire du certificat et permet aux parties de communiquer de manière sécurisée grâce au chiffrement.

Les certificats numériques fournissent les services suivants :

  • Chiffrement : ils aident à protéger les données échangées contre le vol ou la falsification.

  • Authentification : ils vérifient que leurs titulaires (personnes, sites web et même périphériques réseau tels que les routeurs) sont véritablement qui ou ce qu’ils prétendent être. En règle générale, l'authentification est à sens unique, où la source vérifie l'identité de la cible, mais l'authentification Mutual TLS est également possible.

Les certificats sont émis à différentes fins. Par exemple, pour l'authentification des utilisateurs web, l'authentification de serveurs web, le chiffrement S/MIME (Secure/Multipurpose Internet Mail Extensions), IPsec et la signature de code.

Un certificat contient une clé publique qu'il attache à l'identité de la personne, de l'ordinateur ou du service contenant la clé privée correspondante. Les clés publiques et privées permettent au client et au serveur de chiffrer les données avant de les transmettre. Pour les utilisateurs de Windows et les ordinateurs et services utilisant ce programme, l'approbation d'une autorité de certification est établie lorsque le certificat racine est défini dans le magasin de certificats racines approuvés et que le certificat contient un chemin d'accès de certification valide. Un certificat est considéré comme valide s'il n'a pas été révoqué (il ne figure pas dans la liste de révocation de certificats) ou n'est pas arrivé à expiration.

Les trois principaux types de certificats numériques sont décrits dans le tableau suivant.

Type Description Avantages Inconvénients
Certificat auto-signé Le certificat est signé par l'application qui l'a créé. Coût (gratuit). Le certificat n'est pas automatiquement approuvé par les ordinateurs client et les appareils mobiles. Le certificat doit être ajoutée manuellement au magasin de certificats racine approuvés sur tous les ordinateurs client et appareils, mais certains appareils mobiles ne permettent pas de modifier le magasin de certificats racine approuvés.

Certains services n'utilisent pas de certificats auto-signés.

Difficile d'établir une infrastructure pour Certificate Lifecycle Management. Par exemple, les certificats auto-signés ne peuvent pas être révoqués.

Certificat émis par une autorité de certification interne Le certificat est délivré par une infrastructure à clé publique dans votre organisation. Les services de certificat (AD SC) Active Directory constituent un exemple. Pour plus d'informations, reportez-vous à la rubrique Vue d'ensemble des services de certificats Active Directory. Permet aux organisations d'émettre propres certificats.

Moins cher que les certificats d'une autorité de certification commerciale.

Complexité accrue pour déployer et gérer l'infrastructure à clé publique.

Le certificat n'est pas automatiquement approuvé par les ordinateurs client et les appareils mobiles. Le certificat doit être ajoutée manuellement au magasin de certificats racine approuvés sur tous les ordinateurs client et appareils, mais certains appareils mobiles ne permettent pas de modifier le magasin de certificats racine approuvés.

Certificat émis par une autorité de certification commerciale Le certificat est acheté auprès d'une autorité de certification commerciale approuvée. Déploiement d'un certificat simplifié, étant donné que tous les clients, les appareils et les serveurs approuvent automatiquement les certificats. Coût. Vous devez réaliser une planification afin de réduire le nombre de certificats requis.

Pour prouver l’identité d’un détenteur de certificat, le certificat doit identifier précisément le titulaire du certificat sur d’autres clients, appareils ou serveurs. Les trois méthodes de base pour effectuer cette action sont décrites dans le tableau suivant.

Méthode Description Avantages Inconvénients
Correspondance d'objet de certificat Le champ Subject du certificat contient le nom commun de l'hôte. Par exemple, le certificat qui est délivré à www.contoso.com peut être utilisé pour le site web https://www.contoso.com. Compatible avec tous les clients, les appareils et les services.

Cloisonnement. La révocation du certificat pour un hôte n'a pas d'incidence sur les autres hôtes.

Nombre de certificats requis. Vous pouvez uniquement utiliser le certificat de l'hôte spécifié. Par exemple, vous ne pouvez pas utiliser le certificat www.contoso.com pour ftp.contoso.com, même lorsque les services sont installés sur le même serveur.

Complexité. Sur un serveur web, chaque certificat requiert sa propre liaison d'adresse IP.

Correspondance d'autre nom de l'objet (SAN) de certificat En plus du champ Subject, le champ Subject Alternative Name du certificat contient une liste de plusieurs noms d'hôte. Par exemple :
  • www.contoso.com
  • ftp.contoso.com
  • ftp.eu.fabirkam.net
Simplicité. Vous pouvez utiliser le même certificat pour plusieurs hôtes dans différents domaines distincts.

La plupart des clients, des appareils et des services prennent en charge les certificats SAN.

Audit et sécurité. Vous savez exactement quels hôtes sont en mesure d'utiliser le certificat SAN.

Plus de planification requise. Vous devez fournir la liste des hôtes lorsque vous créez le certificat.

Manque de cloisonnement. Vous ne pouvez pas révoquer de manière sélective des certificats pour certains des hôtes spécifiés sans avoir une incidence sur l'ensemble des hôtes du certificat.

Correspondance de certificat générique The certificate's Subject field contains the common name as the wildcard character (*) plus a single domain or subdomain. For example, *.contoso.com or *.eu.contoso.com. The *.contoso.com wildcard certificate can be used for:
  • www.contoso.com
  • ftp.contoso.com
  • mail.contoso.com
Flexibilité. Vous n’avez pas besoin de fournir une liste d’hôtes lorsque vous demandez le certificat, et vous pouvez l’utiliser sur n’importe quel nombre d’hôtes dont vous aurez peut-être besoin à l’avenir. Vous ne pouvez pas utiliser les certificats génériques avec d'autres domaines de premier niveau (TLD). Par exemple, vous ne pouvez pas utiliser le certificat générique *.contoso.com pour les hôtes *.contoso.net.

Vous pouvez uniquement utiliser des certificats génériques pour les noms d'hôtes au niveau du caractère générique. Par exemple, vous ne pouvez pas utiliser le certificat *.contoso.com pour www.eu.contoso.com. Vous ne pouvez pas utiliser le certificat *.eu.contoso.com pour www.uk.eu.contoso.com.

Les anciens clients, appareils, applications ou services peuvent ne pas prendre en charge les certificats génériques.

Les caractères génériques ne sont pas disponibles avec les certificats de validation étendue.

Un audit et un contrôle minutieux sont requis. Si le certificat générique n'est pas fiable, cela affecte tous les hôtes du domaine spécifié.

Certificats dans Exchange

Lorsque vous installez Exchange 2016 ou Exchange 2019 sur un serveur, deux certificats auto-signés sont créés et installés par Exchange. Un troisième certificat auto-signé est créé et installé par Microsoft Windows pour le service de gestion Web dans Internet Information Services (IIS). Ces trois certificats sont visibles dans la Centre d'administration Exchange (CAE) et l'Environnement de ligne de commande Exchange Management Shell, et sont décrits dans le tableau suivant :

Nom Commentaires
Microsoft Exchange Ce certificat auto-signé Exchange offre les possibilités suivantes :
  • Le certificat est automatiquement approuvé par tous les autres serveurs Exchange de l’organisation. Cela inclut tous les serveurs de transport Edge abonnés à l’Exchange organisation.
  • Le certificat est automatiquement activé pour tous les services Exchange, à l'exception de la messagerie unifiée. Il est utilisé pour chiffrer les communications internes entre les serveurs Exchange, les services Exchange sur le même ordinateur et les connexions client transmises par proxy depuis les services d'accès client vers les services principaux sur les serveurs de boîte aux lettres. (Remarque : la um n’est pas disponible Exchange 2019.)
  • Le certificat est automatiquement activé pour les connexions entrantes provenant des serveurs de messagerie SMTP externes, ainsi que pour les connexions sortantes vers les serveurs de messagerie SMTP externes. Cette configuration par défaut permet Exchange fournir un TLS opportuniste sur toutes les connexions SMTP entrantes et sortantes. Exchange tente de chiffrer la session SMTP avec un serveur de messagerie externe, mais si le serveur externe ne prend pas en charge le chiffrement TLS, la session n'est pas chiffrée.
  • Le certificat ne fournit pas de communication chiffrée avec des clients internes ou externes. Les clients et les serveurs n'approuvent pas le certificat auto-signé Exchange, car le certificat n'est pas défini dans leurs magasins de certifications racine approuvées.
Certificat d'authentification serveur Microsoft Exchange Le certificat auto-signé Exchange est utilisé pour l'authentification de serveur à serveur et l'intégration à l'aide de OAuth. Pour plus d’informations, voir Plan Exchange Server integration with SharePoint and Skype Entreprise.
WMSvc Le certificat auto-signé Windows est utilisé par le service de gestion Web dans IIS pour activer la gestion à distance des applications et du serveur web, ainsi que ses sites web associés.

Si vous supprimez ce certificat, le service de gestion Web ne parvient pas à démarrer si aucun certificat valide n'est sélectionné. Quand le service a cet état, cela peut vous empêcher d'installer les mises à jour Exchange ou de désinstaller Exchange du serveur. Pour obtenir des instructions sur la façon de corriger ce problème, voir ID d’événement 1007 - Authentification Service de gestion Web IIS

Les propriétés des certificats auto-signés sont décrites dans la section concernant les Propriétés des certificats auto-signés par défaut.

Vous devez prendre en considération les problèmes essentiels suivants quand il s'agit de certificats dans Exchange :

  • Vous n'avez pas besoin de remplacer le certificat auto-signé Microsoft Exchange pour chiffrer le trafic réseau entre les serveurs Exchange et les services dans votre organisation.

  • Vous avez besoin de certificats supplémentaires pour chiffrer les connexions aux serveurs Exchange via les clients internes et externes.

  • Vous avez besoin de certificats supplémentaires pour forcer le chiffrement des connexions SMTP entre les serveurs Exchange et les serveurs de messagerie externes.

Les éléments suivants de planification et de déploiement pour Exchange Server sont des facteurs importants pour vos exigences de certificat :

Conditions requises pour les certificats des services Exchange

Les services Exchange auxquels les certificats peuvent être affectés sont décrits dans le tableau suivant.

Service Description
IIS (HTTP) Par défaut, les services suivants sont proposées sous le site web par défaut dans les services d'accès client (frontal) sur un serveur de boîte aux lettres et sont utilisés par les clients pour vous connecter à Exchange :
  • Découverte automatique
  • Exchange ActiveSync
  • Centre d'administration Exchange
  • Services Web Exchange
  • Distribution de carnet d'adresses en mode hors connexion
  • Outlook Anywhere (RPC sur HTTP)
  • Outlook MAPI sur HTTP
  • Outlook sur le web
  • Remote PowerShell*

Étant donné que vous ne pouvez associer qu'un seul certificat à un site web, tous les noms DNS que les clients utilisent pour se connecter à ces services doivent être inclus dans le certificat. Vous pouvez y parvenir à l'aide d'un certificat de SAN ou d'un certificat générique.

POP ou IMAP Les certificats utilisés pour POP ou IMAP peuvent être différents du certificat utilisé pour IIS. Cependant, pour simplifier l'administration, nous vous recommandons d'inclure les noms d'hôtes utilisés pour POP ou IMAP dans le certificat IIS et d'utiliser le même certificat pour tous les services.
SMTP Les connexions SMTP à partir des clients ou des serveurs de messagerie sont acceptées par un ou plusieurs connecteurs de réception configurés dans le service de transport frontal sur le serveur Exchange. Pour plus d'informations, reportez-vous à la rubrique Connecteurs de réception.

Pour demander le chiffrement TLS des connexions SMTP, vous pouvez utiliser un certificat distinct pour chaque connecteur de réception. Le certificat doit inclure le nom DNS utilisé par les clients SMTP ou les serveurs afin de se connecter au connecteur de réception. Pour simplifier la gestion des certificats, ajoutez tous les noms DNS dont vous devez prendre en charge le trafic TLS dans un seul certificat.

Pour exiger l’authentification TLS mutuelle, où les connexions SMTP entre les serveurs source et de destination sont chiffrées et authentifiées, voir Sécurité du domaine.

Messagerie unifiée (UM) Pour plus d'informations, reportez-vous à la rubrique Deploying Certificates for UM.

Remarque : la um n’est pas disponible Exchange 2019.

Déploiement hybride avec Microsoft 365 ou Office 365 Pour plus d'informations, reportez-vous à la rubrique Certificate Requirements for Hybrid Deployments.
S/MIME (Secure/Multipurpose Internet Mail Extension) Pour plus d'informations, reportez-vous à la rubrique S/MIME pour la signature et le chiffrement des messages.

*L’authentification Kerberos et le chiffrement Kerberos sont utilisés pour l’accès PowerShell à distance, à partir du centre d’administration Exchange et de l’Exchange Management Shell. Par conséquent, vous n'avez pas besoin configurer vos certificats pour une utilisation avec PowerShell à distance, dans la mesure où vous vous connectez directement à un serveur Exchange (et non à un espace de noms d'équilibrage de charge). Pour utiliser PowerShell à distance pour vous connecter à un serveur Exchange à partir d’un ordinateur qui n’est pas membre du domaine ou pour vous connecter à partir d’Internet, vous devez configurer vos certificats pour une utilisation avec PowerShell à distance.

Meilleures pratiques pour les certificats Exchange

Bien que la configuration des certificats numériques de votre organisation varie selon ses besoins, des recommandations sont incluses pour vous aider à choisir la configuration de certificat numérique qui vous convient.

  • Utilisez aussi peu de certificats que possible : il est très probable que cela implique l’utilisation de certificats SAN ou de certificats génériques. En matière d'interopérabilité avec Exchange, les deux fonctionnalités sont équivalentes. La décision d'utiliser un certificat SAN ou un certificat générique est prise en fonction des fonctionnalités clés ou des limitations (réelles ou perçues) pour chaque type de certificat, comme indiqué dans la Vue d'ensemble des certificats numériques.

    Par exemple, si tous les noms communs se trouvent au même niveau que contoso.com, peu importe que vous utilisiez un certificat SAN ou un certificat générique. Cependant, si vous devez utiliser le certificat pour autodiscover.contoso.com, autodiscover.fabrikam.com et autodiscover.northamerica.contoso.com, vous devez utiliser un certificat SAN.

  • Utilisez les certificats d’une ca commerciale pour les connexions client et serveur externe : bien que vous pouvez configurer la plupart des clients pour qu’ils font confiance à un certificat ou à un émetteur de certificat, il est beaucoup plus facile d’utiliser un certificat d’une cae commerciale pour les connexions client à vos serveurs Exchange. Aucune configuration n'est requise sur le client afin d'approuver un certificat émis par une autorité de certification commerciale. Plusieurs autorités de certification commerciales proposent des certificats qui sont configurés spécifiquement pour Exchange. Vous pouvez utiliser le CAE ou le Environnement de ligne de commande Exchange Management Shell pour générer des demandes de certificat qui fonctionnent avec la plupart des autorités de certification commerciales.

  • Choisissez l’ac commerciale la plus à même de choisir : comparez les prix et les fonctionnalités des certificats entre les ca. Par exemple :

    • Vérifiez que l'autorité de certification est approuvée par les clients (systèmes d'exploitation, navigateurs et appareils mobiles) qui se connecteront à vos serveurs Exchange.

    • Assurez-vous que l'autorité de certification prend en charge le type de certificat dont vous avez besoin. Par exemple, certaines autorités de certification ne prennent pas en charge les certificats SAN, l'autorité de certification peut limiter le nombre de noms communs que vous pouvez utiliser un certificat de SAN, ou l'autorité de certification peut facturer des frais supplémentaires en fonction du nombre de noms communs dans un certificat SAN.

    • Déterminez si l'autorité de certification propose une période de grâce pendant laquelle vous pouvez ajouter des noms communs supplémentaires à des certificats SAN après leur émission sans être facturé.

    • Vérifiez que la licence du certificat vous autorise à utiliser le certificat sur le nombre requis de serveurs. Certaines autorités de certification vous permettent d'utiliser le certificat sur un serveur.

  • Utilisez l’Assistant Certificat Exchange : une erreur courante lorsque vous créez des certificats consiste à oublier un ou plusieurs noms communs requis pour les services que vous souhaitez utiliser. L'Assistant Certificat dans le Centre d'administration Exchange vous permet d'inclure la bonne liste des noms communs dans la demande de certificat. L'Assistant vous permet de spécifier les services qui utilisent le certificat, et inclut les noms communs dont vous devez disposer dans le certificat de ces services. Exécutez l’Assistant Certificat lorsque vous avez déployé votre ensemble initial de serveurs Exchange 2016 ou Exchange 2019 et déterminé les noms d’hôte à utiliser pour les différents services de votre déploiement.

  • Utilisez aussi peu de noms d’hôte que possible : réduire le nombre de noms d’hôtes dans les certificats SAN réduit la complexité de la gestion des certificats. Ne vous sentez pas obligé d'inclure des noms d'hôtes de serveurs Exchange individuels dans les certificats SAN si l'utilisation prévue du certificat ne le nécessite pas. En règle générale, vous ne devez inclure que les noms DNS présentés aux clients internes, aux clients externes ou aux serveurs externes qui utilisent le certificat pour se connecter à Exchange.

    Pour une organisation Exchange Server simple appelée Contoso, il s’agit d’un exemple hypothétique de noms d’hôtes minimaux qui serait requis :

    • mail.contoso.com : ce nom d’hôte couvre la plupart des connexions aux Exchange, notamment Outlook, Outlook sur le web, distribution du OAB, services web Exchange, centre d’administration Exchange et Exchange ActiveSync.

    • autodiscover.contoso.com : ce nom d’hôte spécifique est requis par les clients qui la prise en charge de la découverte automatique, notamment les clients Outlook, Exchange ActiveSync et Exchange Services Web. Pour en savoir plus, consultez la rubrique Service de découverte automatique.

Propriétés des certificats auto-signés par défaut

Certaines des propriétés plus intéressantes des certificats auto-signés par défaut visibles dans le Centre d'administration Exchange et/ou le Environnement de ligne de commande Exchange Management Shell sur un serveur Exchange sont décrites dans le tableau suivant.

Propriété Microsoft Exchange Certificat d'authentification serveur Microsoft Exchange WMSvc
Sujet CN=<ServerName> (par exemple, CN=Mailbox01) CN=Microsoft Exchange Server Auth Certificate CN=WMSvc-<ServerName> (par exemple, CN=WMSvc-Mailbox01)
Autres noms du sujet (CertificateDomains) <ServerName> (par exemple, Mailbox01)

<ServerFQDN> (par exemple, Mailbox01.contoso.com)

none WMSvc-<ServerName> (par exemple, WMSvc-Mailbox01)
Dispose d’une clé privée (HasPrivateKey) Oui (True) Oui (True) Oui (True)
PrivateKeyExportable* False True True
EnhancedKeyUsageList* Authentification du serveur (1.3.6.1.5.5.7.3.1) Authentification du serveur (1.3.6.1.5.5.7.3.1) Authentification du serveur (1.3.6.1.5.5.7.3.1)
IISServices* IIS://<ServerName>/W3SVC/1, IIS://<ServerName>/W3SVC/2 (par exemple, IIS://Mailbox01/W3SVC/1, IIS://Mailbox01/W3SVC/2) none none
IsSelfSigned True True True
Issuer CN=<ServerName> (par exemple, CN=Mailbox01) CN=Microsoft Exchange Server Auth Certificate CN=WMSvc-<ServerName> (par exemple, CN=WMSvc-Mailbox01)
NotBefore Date/heure à laquelle Exchange a été installé. Date/heure à laquelle Exchange a été installé. Date/heure à laquelle le service de gestionnaire Web IIS a été installé.
Expire le (NotAfter) 5 ans après NotBefore. 5 ans après NotBefore. 10 ans après NotBefore.
Taille de clé publique (PublicKeySize) 2048 2048 2048
RootCAType Registre Aucun Registre
Services IMAP, POP, IIS, SMTP SMTP Aucun

*Ces propriétés ne sont pas visibles dans l’affichage standard dans Exchange Management Shell. Pour les afficher, vous devez spécifier le nom de la propriété (nom exact ou recherche générique) avec la cmdlet Format-Table ou Format-List. Par exemple :

  • Get-ExchangeCertificate -Thumbprint <Thumbprint> | Format-List *

  • Get-ExchangeCertificate -Thumbprint <Thumbprint> | Format-Table -Auto FriendlyName,*PrivateKey*

Pour plus d’informations, voir Get-ExchangeCertificate.

Plus d'informations sur les certificats auto-signés par défaut qui sont visibles dans le gestionnaire de certificat Windows sont indiquées dans le tableau suivant.

Propriété Microsoft Exchange Certificat d'authentification serveur Microsoft Exchange WMSvc
Algorithme de signature sha256RSA1 sha256RSA1 sha256RSA1
Algorithme de hachage de signature sha2561 sha2561 sha2561
Utilisation de la clé Signature numérique, cryptage de la clé (a0) Signature numérique, cryptage de la clé (a0) Signature numérique, chiffrage de clés (a0), chiffrement des données (b0 00 00 00)
Contraintes de base Subject Type=End Entity

Path Length Constraint=None

Subject Type=End Entity

Path Length Constraint=None

s/o
Algorithme d'empreinte sha2561 sha2561 sha2561

1 S’applique aux nouvelles installations de la mise à jour cumulative Exchange 2016 22 ou ultérieure et de la mise à jour cumulative Exchange 2019 2019 11 ou ultérieure. Pour plus d’informations, Exchange Server certificats 2019 et 2016 créés lors de l’installation utilisent le hachage SHA-1.

En règle générale, n'utilisez pas le gestionnaire de certificat Windows pour gérer les certificats Exchange (utilisez Centre d'administration Exchange ou Environnement de ligne de commande Exchange Management Shell). Le certificat WMSvc n'est pas un certificat Exchange.