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 protocole TLS (Transport Layer Security) pour chiffrer la communication 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.
Remarque
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 Exchange Server bonnes pratiques en matière de configuration TLS.
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 connaître les procédures requises pour les certificats dans Exchange Server, consultez 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 vraiment 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 émis à www.contoso.com peut être utilisé pour le site https://www.contoso.comweb . | 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 :
|
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 | Le champ Subject du certificat contient le nom commun comme caractère générique (*) ainsi qu’un domaine unique ou un sous-domaine. Par exemple, contoso.com ou *.eu.contoso.com. Le certificat générique *.contoso.com peut être utilisée dans les cas suivants :
|
Flexibilité. Vous n’avez pas besoin de fournir une liste d’hôtes lorsque vous demandez le certificat, et vous pouvez utiliser le certificat sur n’importe quel nombre d’hôtes dont vous pourriez avoir 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. Ou 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 :
|
| 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 Planifier l’intégration Exchange Server à SharePoint et 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, consultez ID d’événement 1007 - Authentification du 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 :
Équilibrage de charge : envisagez-vous d’arrêter le canal chiffré au niveau de l’équilibreur de charge ou du serveur proxy inverse, d’utiliser des équilibreurs de charge de couche 4 ou de couche 7 et d’utiliser l’affinité de session ou aucune affinité de session ? Pour plus d'informations, reportez-vous à la rubrique sur l'équilibrage de charge dans Exchange 2016.
Planification de l’espace de noms : quelles versions d’Exchange sont présentes, utilisez-vous le modèle d’espace de noms lié ou indépendant, et utilisez-vous le DNS à cerveau fractionné (configuration d’adresses IP différentes pour le même hôte en fonction de l’accès interne et externe) ? Pour plus d'informations, consultez l'article de blog sur la planification de l'espace de noms dans Exchange 2016.
Connectivité client : quels services vos clients utiliseront-ils (services web, POP, IMAP, etc.) et quelles versions d’Exchange sont impliquées ? Pour plus d’informations, voir les rubriques suivantes :
Prise en charge des certificats de chiffrement à courbe elliptique dans Exchange Server
Les certificats ECC, ou certificats de chiffrement à courbe elliptique, sont un type de certificat numérique qui utilise l’algorithme de courbe elliptique pour le chiffrement, offrant une sécurité plus forte avec des longueurs de clés plus courtes que les certificats RSA traditionnels.
À compter de la mise à jour du correctif logiciel (HU) Exchange Server avril 2024, Exchange Server 2016 et Exchange Server 2019 prend en charge l’utilisation de certificats ECC (Elliptic Curve Cryptography) pour certains services. Nous avons apporté des ajustements importants à la mise à jour de sécurité Exchange Server novembre 2024 pour résoudre les problèmes connus et activer la prise en charge des certificats ECC pour d’autres scénarios (par exemple, POP3 et IMAP). Veillez à installer la dernière mise à jour Exchange Server avant d’activer la prise en charge des certificats ECC.
Avertissement
Les scénarios suivants ne prennent actuellement pas en charge l’utilisation de certificats ECC. Nous travaillons sur une mise à jour pour prendre en charge ces scénarios à l’avenir :
- Le certificat d’approbation de fédération doit être un certificat RSA
- Le certificat OAuth Exchange Server doit être un certificat RSA
- Les certificats ECC ne peuvent pas être utilisés lorsque l’utilisation de l’authentification basée sur les revendications AD FS est configurée
Consultez le tableau de la section suivante pour comprendre quels services peuvent être utilisés avec un certificat ECC.
La prise en charge des certificats ECC est désactivée par défaut et peut être activée en créant une valeur de Registre. La commande doit être exécutée sur chaque Exchange Server de votre organization. Jusqu’à 15 minutes peuvent être nécessaires avant que la modification ne devienne active.
New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\ExchangeServer\v15\Diagnostics" -Name "EnableEccCertificateSupport" -Value 1 -Type String
Le remplacement, qui a été introduit avec la Exchange Server mise à jour du correctif logiciel (HU) d’avril 2024, ne doit plus être utilisé, car il n’active pas entièrement la prise en charge des certificats ECC.
Nous vous recommandons de supprimer le remplacement. Ouvrez un nouvel environnement de ligne de commande Exchange Management Shell (EMS) après l’exécution de la New-SettingOverride commande :
Get-SettingOverride | Where-Object {($_.SectionName -eq "ECCCertificateSupport") -and ($_.Parameters -eq "Enabled=true")} | Remove-SettingOverride
Get-ExchangeDiagnosticInfo -Process Microsoft.Exchange.Directory.TopologyService -Component VariantConfiguration -Argument Refresh
Restart-Service -Name W3SVC, WAS -Force
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 | Certificat ECC pris en charge |
|---|---|---|
| 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 :
É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. |
Oui |
| 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. | Oui |
| 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, consultez Sécurité du domaine. |
Oui |
| EdgeSync | Pour plus d’informations, consultez Abonnements Edge dans Exchange Server | Non |
| Messagerie unifiée (UM) | Pour plus d'informations, reportez-vous à la rubrique Deploying Certificates for UM. Remarque : la messagerie unifiée n’est pas disponible dans Exchange 2019. |
Oui |
| Déploiement hybride avec Microsoft 365 ou Office 365 | Pour plus d'informations, reportez-vous à la rubrique Certificate Requirements for Hybrid Deployments. | Oui |
| S/MIME (Secure/Multipurpose Internet Mail Extensions) | Pour plus d'informations, reportez-vous à la rubrique S/MIME pour la signature et le chiffrement des messages. | Non |
* L'authentification Kerberos et le chiffrement Kerberos sont utilisés pour l'accès à distance PowerShell, à la fois le Centre d'administration Exchange et le Environnement de ligne de commande 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 distant.
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 le moins de certificats possible : très probablement, cela signifie utiliser des certificats SAN ou des 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.
Utiliser des certificats d’une autorité de certification commerciale pour les connexions client et serveur externe : bien que vous puissiez configurer la plupart des clients pour approuver n’importe quel certificat ou émetteur de certificat, il est beaucoup plus facile d’utiliser un certificat d’une autorité de certification 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’autorité de certification commerciale appropriée : Comparez les prix et les fonctionnalités des certificats entre les autorités de certification. 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.
Utiliser 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 que vous avez déterminé les noms d’hôte à utiliser pour les différents services pour votre déploiement.
Utilisez le moins de noms d’hôte possible : la réduction du nombre de noms d’hôtes dans les certificats SAN réduit la complexité impliquée dans 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 un Exchange Server organization simple nommé Contoso, il s’agit d’un exemple hypothétique des noms d’hôtes minimaux qui seraient requis :
mail.contoso.com : ce nom d’hôte couvre la plupart des connexions à Exchange, y compris Outlook, Outlook sur le web, la distribution du carnet d’adresses en mode hors connexion, les services Web Exchange, le Centre d’administration Exchange et Exchange ActiveSync.
autodiscover.contoso.com : ce nom d’hôte spécifique est requis par les clients qui prennent en charge la découverte automatique, notamment outlook, Exchange ActiveSync et les clients des services web Exchange. 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 |
|---|---|---|---|
| Subject |
CN=<ServerName> (par exemple, CN=Mailbox01) |
CN=Microsoft Exchange Server Auth Certificate |
CN=WMSvc-<ServerName> (par exemple, CN=WMSvc-Mailbox01) |
| Autres noms d’objet (CertificateDomains) |
<ServerName> (par exemple, Mailbox01) <ServerFQDN> (par exemple, Mailbox01.contoso.com) |
none |
WMSvc-<ServerName> (par exemple, WMSvc-Mailbox01) |
| A une clé privée (HasPrivateKey) | Oui (True) | Oui (True) | Oui (True) |
| PrivateKeyExportable* | Faux | 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 la vue standard dans le Environnement de ligne de commande 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, consultez 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 |
Subject Type=End Entity |
s/o |
| Algorithme d'empreinte | sha2561 | sha2561 | sha2561 |
1 S’applique aux nouvelles installations de la mise à jour cumulative 22 d’Exchange 2016 ou ultérieure et de la mise à jour cumulative 11 d’Exchange 2019 ou ultérieure. Pour plus d’informations, consultez Exchange Server certificats 2019 et 2016 créés pendant l’installation utiliser 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.