Cet article a fait l’objet d’une traduction automatique. Pour afficher l’article en anglais, activez la case d’option Anglais. Vous pouvez également afficher le texte anglais dans une fenêtre contextuelle en faisant glisser le pointeur de la souris sur le texte traduit.
Traduction
Anglais

Certificats numériques et chiffrement dans Exchange 2016

[Cette rubrique est une documentation préliminaire et peut être modifiée dans les versions ultérieures. Des rubriques vides sont incluses comme espaces réservés. N’hésitez pas à nous transmettre vos commentaires. Envoyez-nous un e-mail à l’adresse ExchangeHelpFeedback@microsoft.com.]  

S’applique à :Exchange Server 2016

En savoir plus sur les certificats SSL, TLS, de chiffrement et numériques dans Exchange 2016.

Les certificats de chiffrement et numériques représentent des considérations importantes dans n’importe quelle organisation. Par défaut, Exchange Server 2016 est configuré pour utiliser le chiffrement 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.

noteRemarque :
Le protocole SSL (Secure Sockets Layer) est remplacé par le protocole TLS (Transport Layer Security) comme protocole utilisé pour chiffrer les données envoyées entre des systèmes informatiques. Ils sont si étroitement liés que les termes « SSL » et « TLS » (sans versions) sont souvent utilisés indifféremment. En raison de cette similitude, les références à « SSL » dans les rubriques concernant Exchange, dans le Centre d’administration Exchange et dans l’Environnement de ligne de commande Exchange Management Shell recouvrent souvent les protocoles SSL et TLS. En règle générale, « SSL » fait référence au véritable protocole SSL uniquement lorsqu’une version est également fournie (par exemple, SSL 3.0). Pour savoir pourquoi vous devez désactiver le protocole SSL et passer au protocole TLS, consultez l’article relatif à la protection contre la vulnérabilité du protocole SSL 3.0.

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 qui sont requises pour les certificats dans Exchange 2016, reportez-vous à la rubrique Gestion des certificats dans Exchange 2016.

Contenu de cette rubrique

Vue d'ensemble des certificats numériques

Certificats dans Exchange

Conditions requises pour les certificats des services Exchange

Meilleures pratiques pour les certificats Exchange

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

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 permettent de protéger les données échangées suite à un vol ou à une falsification.

  • Authentification   Ils vérifient que leurs titulaires (personnes, sites web et même les appareils réseau tels que les routeurs) sont véritablement ceux 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.

 

Entrez DescriptionAvantagesInconvé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éthodeDescriptionAvantagesInconvé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

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 :

  • 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. Vous pouvez utiliser le certificat sur autant d’hôtes que nécessaire à 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é.

Retour au début

Lorsque vous installez Exchange 2016 sur un serveur, deux certificats auto-signés sont créés et installés par Exchange. Un certificat auto-signé tiers est créé et installé par MicrosoftWindows pour le service de gestion Web dans Services Internet (IIS) (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 :

 

NomCommentaires

Microsoft Exchange

Ce certificat auto-signé Exchange offre les possibilités suivantes :

  • Le certificat est automatiquement approuvé par tous les autres serveurs de Exchange de l’organisation. Cela inclut tout Serveur de transport Edge souscrit à l’organisation Exchange.

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

  • 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 de 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, reportez-vous à la rubrique Planifier l’intégration d’Exchange 2016 avec 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 savoir comment corriger ce problème, reportez-vous à la rubrique relative à l’ID d’événement 1007 — Authentification de 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 la planification et du déploiement d’Exchange 2016 sont des axes stratégiques importants pour vos exigences en matière de certificat :

Retour au début

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

 

ServiceDescription

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

  • PowerShell distant*

É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 demander une authentification Mutual TLS, où les connexions SMTP entre les serveurs source et cible sont à la fois chiffrés et authentifiés, reportez-vous à la rubrique Domain Security.

Messagerie unifiée (UM)

Pour plus d'informations, reportez-vous à la rubrique Déploiement de certificats pour la messagerie unifiée.

Déploiement hybride avec Microsoft Office 365

Pour plus d'informations, reportez-vous à la rubrique Conditions requises pour les certificats dans le cadre de déploiements hybrides.

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 à 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 afin de vous connecter à un serveur Exchange à partir d’un ordinateur qui n’est pas membre du domaine, ou de vous connecter à partir d’Internet, vous devez configurer vos certificats à utiliser avec PowerShell à distance.

Retour au début

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.

  • Utiliser aussi peu de certificats que possible   Cela implique d’utiliser des certificats SAN ou 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.

    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 les certificats provenant d’une autorité de certification commerciale pour les connexions client et serveur externe   Bien que vous puissiez configurer la plupart des clients pour approuver des certificats ou l’émetteur du certificat, il est beaucoup plus facile d’utiliser un certificat provenant 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.

  • Choisir l’autorité de certification commerciale appropriée   Comparez les prix des certificats et les fonctionnalités entre les autorités de certification. Par exemple :

    • Choisissez une autorité de certification qui indique qu'elle prend en charge les certificats de « communications unifiées » pour utilisation avec Exchange. Pour plus d’informations, reportez-vous à la rubrique Partenaires de certificat de Communications unifiées.

    • 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’ExchangeAssistant Certificat   Une erreur courante lorsque vous créez des certificats est d’oublier un ou plusieurs noms communs obligatoires 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 et déterminé les noms d'hôtes à utiliser pour les différents services du déploiement.

  • Utiliser aussi peu de noms d’hôtes que possible   Limiter le nombre de noms d’hôtes dans les certificats SAN réduit la complexité liée à 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.

    Voici un exemple hypothétique du nombre minimal de noms d’hôtes requis pour une organisation Exchange 2016 simple nommée Contoso :

    • mail.contoso.com   Cet hôte couvre la plupart des connexions à Exchange, y compris Outlook, Outlook sur le web, distribution de carnet d'adresses en mode hors connexion, Services Web Exchange, POP3, IMAP4, SMTP, 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 les Découverte automatique, y compris les clients Outlook, Exchange ActiveSync et Services Web Exchange. Pour plus d’informations, consultez Service de découverte automatique.

    • legacy.contoso.com   Ce nom d’hôte est requis dans un scénario de coexistence avec Exchange 2010. Si vous avez des clients avec des boîtes aux lettres sur des serveurs Exchange 2010, configurez un nom d’hôte hérité pour éviter que les utilisateurs aient à utiliser une seconde URL au cours du processus de mise à niveau.

Retour au début

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.

 

Nom (FriendlyName*)

Microsoft Exchange

Microsoft ExchangeCertificat d’authentification de serveur

WMSvc

Objet

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.

aucune

WMSvc-<ServerName>   Par exemple, WMSvc-Mailbox01.

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

aucune

aucune

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

Date d’expiration (NotAfter)

5 ans après NotBefore.

5 ans après NotBefore.

10 ans après NotBefore.

Taille de la 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, reportez-vous à la rubrique 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.

 

Nom convivial

Microsoft Exchange

Microsoft ExchangeCertificat d’authentification de serveur

WMSvc

Algorithme de signature

sha1RSA

sha1RSA

sha1RSA

Algorithme de hachage de signature

sha1

sha1

sha1

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

sha1

sha1

sha1

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.

Retour au début

 
Afficher: