Partager via

Certificats numériques et SSL

  • Article

S’applique à : Exchange Server 2013

Ssl (Secure Sockets Layer) est une méthode de sécurisation des communications entre un client et un serveur. Pour Exchange Server 2013, SSL est utilisé pour sécuriser les communications entre le serveur et les clients. Les clients peuvent être des téléphones mobiles, des ordinateurs faisant partie du réseau d’une organisation et des ordinateurs extérieurs au réseau d’une organisation.

Par défaut, lorsque vous installez Exchange 2013, les communications clientes sont chiffrées à l’aide de SSL lorsque vous utilisez Outlook Web App, Exchange ActiveSync et Outlook Anywhere.

Le protocole SSL nécessite l’utilisation de certificats numériques. Cette rubrique résume les différents types de certificats numériques et des informations sur la configuration d’Exchange 2013 pour utiliser ces types de certificats numériques.

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é SSL utilisé pour les communications client. Un certificat est une déclaration numérique émise par une autorité de certification qui garantit l’identité du titulaire du certificat et permet aux parties de communiquer de manière sécurisée à l’aide du chiffrement.

Les certificats numériques effectuent les actions suivantes :

  • Ils authentifient que leurs titulaires (personnes, sites web et même ressources réseau telles que les routeurs) sont vraiment qui ou ce qu’ils prétendent être.

  • Ils protègent les données échangées en ligne contre le vol ou la falsification.

Les certificats numériques peuvent être émis par une autorité de certification tierce approuvée ou une infrastructure à clé publique (PKI) Windows à l’aide des services de certificats, ou ils peuvent être auto-signés. Chaque type de certificat présente des avantages et des inconvénients. Chaque type de certificat numérique est inviolable et ne peut pas être falsifié.

Les certificats sont émis à différentes fins. Ces utilisations incluent l’authentification des utilisateurs web, l’authentification du serveur web, les extensions S/MIME (Secure/Multipurpose Internet Mail Extensions), IPsec (Internet Protocol Security), TLS (Transport Layer Security) 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 sont utilisées par le client et le serveur pour chiffrer les données avant leur transmission. Pour les utilisateurs, ordinateurs et services Windows, l’approbation d’une autorité de certification est établie lorsqu’il existe une copie du certificat racine dans le magasin de certificats racine approuvé et que le certificat contient un chemin d’accès de certification valide. Pour que le certificat soit valide, le certificat ne doit pas avoir été révoqué et la période de validité ne doit pas avoir expiré.

Types de certificats

Il existe trois principaux types de certificats numériques : les certificats auto-signés, les certificats générés par windows PKI et les certificats tiers.

Certificats auto-signés

Lorsque vous installez Exchange 2013, un certificat auto-signé est automatiquement configuré sur les serveurs de boîtes aux lettres. Un certificat auto-signé est signé par l’application qui l’a créé. L'objet et le nom du certificat correspondent. L’émetteur et l’objet sont définis sur le certificat. Ce certificat auto-signé est utilisé pour chiffrer les communications entre le serveur d’accès au client et le serveur de boîtes aux lettres. Le serveur d’accès au client approuve automatiquement le certificat auto-signé sur le serveur de boîtes aux lettres. Par conséquent, aucun certificat tiers n’est nécessaire sur le serveur de boîtes aux lettres. Lorsque vous installez Exchange 2013, un certificat auto-signé est également créé sur le serveur d’accès au client. Ce certificat auto-signé permet à certains protocoles clients d’utiliser SSL pour leurs communications. Exchange ActiveSync et Outlook Web App peuvent établir une connexion SSL à l'aide d'un certificat auto-signé. Outlook Anywhere ne fonctionne pas avec un certificat auto-signé sur le serveur d’accès au client. Les certificats auto-signés doivent être copiés manuellement dans le magasin de certificats racine approuvé sur l’ordinateur client ou l’appareil mobile. Lorsqu’un client se connecte à un serveur via SSL et que le serveur présente un certificat auto-signé, le client est invité à vérifier que le certificat a été émis par une autorité approuvée. Le client doit faire explicitement confiance à l’autorité émettrice. Si le client confirme l’approbation, les communications SSL peuvent continuer.

Remarque

Par défaut, le certificat numérique installé sur le ou les serveurs de boîtes aux lettres est un certificat auto-signé. Vous n’avez pas besoin de remplacer le certificat auto-signé sur les serveurs de boîtes aux lettres de votre organisation par un certificat tiers approuvé. Le serveur d’accès au client approuve automatiquement le certificat auto-signé sur le serveur de boîtes aux lettres et aucune autre configuration n’est nécessaire pour les certificats sur le serveur de boîtes aux lettres.

Souvent, les petites organisations décident de ne pas utiliser de certificat tiers ou de ne pas installer leur propre infrastructure à clé publique pour émettre leurs propres certificats. Ils peuvent prendre cette décision parce que ces solutions sont trop coûteuses, parce que leurs administrateurs n’ont pas l’expérience et les connaissances nécessaires pour créer leur propre hiérarchie de certificats, ou pour les deux raisons. Le coût est minime et la configuration est simple lorsque vous utilisez des certificats auto-signés. Toutefois, il est beaucoup plus difficile d’établir une infrastructure pour la gestion du cycle de vie des certificats, le renouvellement, la gestion des approbations et la révocation lorsque vous utilisez des certificats auto-signés.

Certificats d’infrastructure à clé publique Windows

Le deuxième type de certificat est un certificat généré par pKI Windows. Une infrastructure à clé publique (PKI) est un système de certificats numériques, d’autorités de certification et d’autorités d’enregistrement qui vérifient et authentifient la validité de chaque partie impliquée dans une transaction électronique à l’aide du chiffrement à clé publique. Lorsque vous implémentez une infrastructure à clé publique dans une organisation qui utilise Active Directory, vous fournissez une infrastructure pour la gestion du cycle de vie des certificats, le renouvellement, la gestion de l’approbation et la révocation. Toutefois, le déploiement de serveurs et d’une infrastructure pour créer et gérer des certificats générés par une infrastructure À clé publique Windows entraîne un coût supplémentaire.

Les services de certificats sont requis pour déployer une infrastructure à clé publique Windows et peuvent être installés via l’ajout ou la suppression de programmes dans Panneau de configuration. Vous pouvez installer les services de certificats sur tous les serveurs du domaine.

Si vous obtenez des certificats à partir d’une autorité de certification Windows jointe à un domaine, vous pouvez utiliser l’autorité de certification pour demander ou signer des certificats à émettre sur vos propres serveurs ou ordinateurs sur votre réseau. Cela vous permet d’utiliser une infrastructure à clé publique qui ressemble à un fournisseur de certificats tiers, mais est plus économique. Ces certificats PKI ne peuvent pas être déployés publiquement, comme d’autres types de certificats. Toutefois, lorsqu’une autorité de certification PKI signe le certificat du demandeur à l’aide de la clé privée, le demandeur est vérifié. La clé publique de cette autorité de certification fait partie du certificat. Un serveur disposant de ce certificat dans le magasin de certificats racines approuvés peut utiliser cette clé publique pour déchiffrer le certificat du demandeur et authentifier celui-ci.

Les étapes de déploiement d’un certificat généré par pKI ressemblent à celles requises pour déployer un certificat auto-signé. Vous devez toujours installer une copie du certificat racine approuvé à partir de l’infrastructure à clé publique sur le magasin de certificats racine approuvé des ordinateurs ou appareils mobiles pour lesquels vous souhaitez établir une connexion SSL à Microsoft Exchange.

Une infrastructure À clé publique Windows permet aux organisations de publier leurs propres certificats. Les clients peuvent demander et recevoir des certificats d’une infrastructure à clé publique Windows sur le réseau interne. L’infrastructure à clé publique Windows peut renouveler ou révoquer des certificats.

Certificats tiers approuvés

Les certificats tiers ou commerciaux sont des certificats générés par une autorité de certification tierce ou commerciale, puis achetés pour que vous les utilisiez sur vos serveurs réseau. L’un des problèmes liés aux certificats auto-signés et basés sur une infrastructure à clé publique est que, étant donné que le certificat n’est pas automatiquement approuvé par l’ordinateur client ou l’appareil mobile, vous devez vous assurer que vous importez le certificat dans le magasin de certificats racine approuvé sur les ordinateurs clients et les appareils. Les certificats tiers ou commerciaux ne rencontrent pas ce problème. La plupart des certificats émis par une autorité de certification commerciale sont déjà approuvés, car le certificat réside déjà dans le magasin de certificats racines approuvés. Étant donné que l'émetteur est approuvé, le certificat l'est également. L'utilisation des certificats tiers simplifie énormément le déploiement.

Pour les grandes organisations ou les organisations qui doivent déployer publiquement des certificats, la meilleure solution consiste à utiliser un certificat tiers ou commercial, même s’il existe un coût associé au certificat. Les certificats commerciaux peuvent ne pas être la meilleure solution pour les petites et moyennes organisations, et vous pouvez décider d’utiliser l’une des autres options de certificat disponibles.

Choix d’un type de certificat

Lorsque vous choisissez le type de certificat à installer, plusieurs éléments sont à prendre en compte. Un certificat doit être signé pour être valide. Il peut être auto-signé ou signé par une autorité de certification. Un certificat auto-signé présente des limitations. Par exemple, tous les appareils mobiles ne permettent pas à un utilisateur d’installer un certificat numérique dans le magasin de certificats racine approuvé. La possibilité d’installer des certificats sur un appareil mobile dépend du fabricant de l’appareil mobile et du fournisseur de services mobiles. Certains fabricants et fournisseurs de services mobiles désactivent l’accès au magasin de certificats racine approuvé. Dans ce cas, ni un certificat auto-signé ni un certificat d’une autorité de certification PKI Windows ne peuvent être installés sur l’appareil mobile.

Certificats Exchange par défaut

Par défaut, Exchange installe un certificat auto-signé sur le serveur d’accès au client et sur le serveur de boîtes aux lettres afin que toutes les communications réseau soient chiffrées. Le chiffrement de toutes les communications réseau nécessite que chaque serveur Exchange dispose d’un certificat X.509 qu’il peut utiliser. Vous devez remplacer ce certificat auto-signé sur le serveur d’accès au client par un certificat approuvé automatiquement par vos clients.

« Auto-signé » signifie qu’un certificat a été créé et signé uniquement par le serveur Exchange lui-même. Étant donné qu’il n’a pas été créé et signé par une autorité de certification généralement approuvée, le certificat auto-signé par défaut ne sera approuvé par aucun logiciel, à l’exception des autres serveurs Exchange de la même organisation. Le certificat par défaut est activé pour tous les services Exchange. Il a un autre nom d’objet (SAN) qui correspond au nom du serveur Exchange sur lequel il est installé. Il contient également une liste de SAN qui incluent à la fois le nom du serveur et le nom de domaine complet (FQDN) du serveur.

Bien que d’autres serveurs Exchange de votre organisation Exchange approuvent automatiquement ce certificat, les clients tels que les navigateurs web, les clients Outlook, les téléphones mobiles et d’autres clients de messagerie en plus des serveurs de messagerie externes ne l’approuveront pas automatiquement. Par conséquent, envisagez de remplacer ce certificat par un certificat tiers approuvé sur vos serveurs d’accès au client Exchange. Si vous avez votre propre infrastructure à clé publique interne et que tous vos clients font confiance à cette entité, vous pouvez également utiliser des certificats que vous émettez vous-même.

Exigences de certificat par service

Les certificats sont utilisés pour plusieurs choses dans Exchange. La plupart des clients utilisent également des certificats sur plusieurs serveurs Exchange. En général, moins vous avez de certificats, plus la gestion des certificats devient plus facile.

Services Internet (IIS)

Tous les services Exchange suivants utilisent le même certificat sur un serveur d’accès au client Exchange donné :

  • Outlook Web App

  • Centre d’administration Exchange (CAE)

  • Services Web Exchange

  • Exchange ActiveSync

  • Outlook Anywhere

  • Découverte automatique

  • Distribution du carnet d’adresses Outlook

Étant donné qu’un seul certificat peut être associé à un site web et que tous ces services sont proposés sous un seul site web par défaut, tous les noms utilisés par les clients de ces services doivent figurer dans le certificat (ou se trouver sous un nom générique dans le certificat).

POP/IMAP

Les certificats utilisés pour POP ou IMAP peuvent être spécifiés séparément du certificat utilisé pour IIS. Toutefois, pour simplifier l’administration, nous vous recommandons d’inclure le nom du service POP ou IMAP dans votre certificat IIS et d’utiliser un certificat unique pour tous ces services.

SMTP

Un certificat distinct peut être utilisé pour chaque connecteur de réception que vous configurez. Le certificat doit inclure le nom que les clients SMTP (ou d’autres serveurs SMTP) utilisent pour atteindre ce connecteur. Pour simplifier la gestion des certificats, envisagez d’inclure tous les noms pour lesquels vous devez prendre en charge le trafic TLS dans un seul certificat.

Certificats numériques et proxy

Le proxy est la méthode par laquelle un serveur envoie des connexions client à un autre serveur. Dans le cas d’Exchange 2013, cela se produit lorsque le serveur d’accès au client proxy une demande cliente entrante au serveur de boîtes aux lettres qui contient la copie active de la boîte aux lettres du client.

Lorsque les serveurs d’accès au client demandent le proxy, SSL est utilisé pour le chiffrement, mais pas pour l’authentification. Le certificat auto-signé sur le serveur de boîtes aux lettres chiffre le trafic entre le serveur d’accès au client et le serveur de boîtes aux lettres.

Proxys et certificats inversés

De nombreux déploiements Exchange utilisent des proxys inversés pour publier des services Exchange sur Internet. Les proxys inverses peuvent être configurés pour arrêter le chiffrement SSL, examiner le trafic en clair sur le serveur, puis ouvrir un nouveau canal de chiffrement SSL à partir des serveurs proxy inverses vers les serveurs Exchange derrière eux. Il s’agit du pontage SSL. Une autre façon de configurer les serveurs proxy inverses consiste à laisser les connexions SSL passer directement aux serveurs Exchange derrière les serveurs proxy inverses. Avec l’un ou l’autre modèle de déploiement, les clients sur Internet se connectent au serveur proxy inverse à l’aide d’un nom d’hôte pour l’accès Exchange, tel que mail.contoso.com. Ensuite, le serveur proxy inverse se connecte à Exchange à l’aide d’un autre nom d’hôte, tel que le nom de l’ordinateur du serveur d’accès au client Exchange. Vous n’avez pas besoin d’inclure le nom de l’ordinateur du serveur d’accès au client Exchange dans votre certificat, car les serveurs proxy inverses les plus courants sont en mesure de faire correspondre le nom d’hôte d’origine utilisé par le client au nom d’hôte interne du serveur d’accès au client Exchange.

SSL et DNS fractionné

Le DNS fractionné est une technologie qui vous permet de configurer différentes adresses IP pour le même nom d’hôte, en fonction de l’origine de la requête DNS d’origine. Cette technologie est également appelée split-horizon DNS, split-view DNS ou split-brain DNS. Le DNS fractionné vous aide à réduire le nombre de noms d’hôte à gérer pour Exchange en autorisant vos clients à se connecter à Exchange via le même nom d’hôte, qu’ils se connectent depuis Internet ou depuis l’intranet. Le DNS fractionné permet aux requêtes qui proviennent de l’intranet de recevoir une adresse IP différente de celle provenant d’Internet.

Le fractionnement du DNS est généralement inutile dans un petit déploiement Exchange, car les utilisateurs peuvent accéder au même point de terminaison DNS, qu’ils proviennent de l’intranet ou d’Internet. Toutefois, avec des déploiements plus importants, cette configuration entraîne une charge trop élevée sur votre serveur proxy Internet sortant et votre serveur proxy inverse. Pour les déploiements plus importants, configurez le DNS fractionné afin que, par exemple, les utilisateurs externes accèdent mail.contoso.com et les utilisateurs internes internal.contoso.com. L’utilisation du DNS fractionné pour cette configuration garantit que vos utilisateurs n’auront pas à se rappeler d’utiliser des noms d’hôte différents en fonction de l’emplacement où ils se trouvent.

Remote Windows PowerShell

L’authentification Kerberos et le chiffrement Kerberos sont utilisés pour l’accès Windows PowerShell à distance, à partir du Centre d’administration Exchange (EAC) et de l’environnement de ligne de commande Exchange Management Shell. Par conséquent, vous n’aurez pas à configurer vos certificats SSL pour une utilisation avec des Windows PowerShell distants.

Bonnes pratiques relatives aux certificats numériques

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.

Bonne pratique : utiliser un certificat tiers approuvé

Pour empêcher les clients de recevoir des erreurs concernant des certificats non approuvés, le certificat utilisé par votre serveur Exchange doit être émis par une personne approuvée par le client. Bien que la plupart des clients puissent être configurés pour approuver n’importe quel certificat ou émetteur de certificat, il est plus simple d’utiliser un certificat tiers approuvé sur votre serveur Exchange. Cela est dû au fait que la plupart des clients approuvent déjà leurs certificats racine. Plusieurs émetteurs de certificats tiers proposent des certificats configurés spécifiquement pour Exchange. Vous pouvez utiliser le CAE pour générer des demandes de certificat qui fonctionnent avec la plupart des émetteurs de certificats.

Comment sélectionner une autorité de certification

Une autorité de certification est une entreprise qui émet et garantit la validité des certificats. Les logiciels clients (par exemple, les navigateurs tels que Microsoft Internet Explorer ou les systèmes d’exploitation tels que Windows ou Mac OS) ont une liste intégrée des autorités de certification auxquels ils font confiance. Cette liste peut généralement être configurée pour ajouter et supprimer des autorités de certification, mais cette configuration est souvent fastidieuse. Utilisez les critères suivants lorsque vous sélectionnez une autorité de certification auprès de laquelle acheter vos certificats :

  • Vérifiez que l’autorité de certification est approuvée par le logiciel client (systèmes d’exploitation, navigateurs et téléphones mobiles) qui se connectera à vos serveurs Exchange.

  • Choisissez une autorité de certification qui indique qu’elle prend en charge les « certificats de communications unifiées » à utiliser avec le serveur Exchange.

  • Assurez-vous que l’autorité de certification prend en charge les types de certificats que vous utiliserez. Envisagez d’utiliser des certificats SAN (Subject Alternative Name). Toutes les autorités de certification ne prennent pas en charge les certificats SAN, et les autres autorités de certification ne prennent pas en charge autant de noms d’hôte que nécessaire.

  • Assurez-vous que la licence que vous achetez pour les certificats vous permet de placer le certificat sur le nombre de serveurs que vous envisagez d’utiliser. Certaines autorités de certification vous permettent de placer un certificat sur un seul serveur.

  • Comparez les prix des certificats entre les autorités de certification.

Bonne pratique : Utiliser des certificats SAN

Selon la façon dont vous configurez les noms de service dans votre déploiement Exchange, votre serveur Exchange peut nécessiter un certificat qui peut représenter plusieurs noms de domaine. Bien qu’un certificat générique, tel qu’un certificat pour *.contoso.com, puisse résoudre ce problème, de nombreux clients ne sont pas à l’aise avec les implications de sécurité de la maintenance d’un certificat qui peut être utilisé pour n’importe quel sous-domaine. Une alternative plus sécurisée consiste à répertorier chacun des domaines requis en tant que SAN dans le certificat. Par défaut, cette approche est utilisée lorsque les demandes de certificat sont générées par Exchange.

Bonne pratique : utiliser l’Assistant Certificat Exchange pour demander des certificats

Il existe de nombreux services dans Exchange qui utilisent des certificats. Une erreur courante lors de la demande de certificats consiste à effectuer la demande sans inclure l’ensemble correct de noms de service. L’Assistant Certificat dans le Centre d’administration Exchange vous aidera à inclure la liste correcte des noms dans la demande de certificat. L’Assistant vous permet de spécifier les services avec lesquels le certificat doit fonctionner et, en fonction des services sélectionnés, inclut les noms que vous devez avoir dans le certificat afin qu’il puisse être utilisé avec ces services. Exécutez l’Assistant Certificat lorsque vous avez déployé votre ensemble initial de serveurs Exchange 2013 et déterminé les noms d’hôte à utiliser pour les différents services pour votre déploiement. Dans l’idéal, vous n’aurez à exécuter l’Assistant Certificat qu’une seule fois pour chaque site Active Directory où vous déployez Exchange.

Au lieu de vous soucier d’oublier un nom d’hôte dans la liste SAN du certificat que vous achetez, vous pouvez utiliser une autorité de certification qui offre, gratuitement, une période de grâce pendant laquelle vous pouvez retourner un certificat et demander le même nouveau certificat avec quelques noms d’hôte supplémentaires.

Bonne pratique : Utiliser le moins de noms d’hôte possible

En plus d’utiliser le moins de certificats possible, vous devez également utiliser le moins de noms d’hôte possible. Cette pratique permet d’économiser de l’argent. De nombreux fournisseurs de certificats facturent des frais en fonction du nombre de noms d’hôtes que vous ajoutez à votre certificat.

L’étape la plus importante que vous pouvez prendre pour réduire le nombre de noms d’hôtes que vous devez avoir et, par conséquent, la complexité de votre gestion des certificats consiste à ne pas inclure des noms d’hôtes de serveur individuels dans les autres noms d’objet de votre certificat.

Les noms d’hôte que vous devez inclure dans vos certificats Exchange sont les noms d’hôte utilisés par les applications clientes pour se connecter à Exchange. Voici une liste de noms d’hôtes classiques qui seraient requis pour une société nommée Contoso :

  • Mail.contoso.com : ce nom d’hôte couvre la plupart des connexions à Exchange, notamment Microsoft Outlook, Outlook Web App, Outlook Anywhere, le carnet d’adresses en mode hors connexion, les services Web Exchange, POP3, IMAP4, SMTP, Exchange Panneau de configuration et ActiveSync.

  • Autodiscover.contoso.com : ce nom d’hôte est utilisé par les clients qui prennent en charge la découverte automatique, notamment Microsoft Office Outlook 2007 et versions ultérieures, Exchange ActiveSync et les clients des services Web Exchange.

  • Legacy.contoso.com : ce nom d’hôte est requis dans un scénario de coexistence avec Exchange 2007 et Exchange 2013. Si vous avez des clients avec des boîtes aux lettres sur Exchange 2007 et Exchange 2013, la configuration d’un nom d’hôte hérité empêche vos utilisateurs d’avoir à apprendre une deuxième URL pendant le processus de mise à niveau.

Présentation des certificats génériques

Un certificat générique est conçu pour prendre en charge un domaine et plusieurs sous-domaines. Par exemple, la configuration d’un certificat générique pour *.contoso.com génère un certificat qui fonctionnera pour mail.contoso.com, web.contoso.com et autodiscover.contoso.com.