Exchange 2016 Series – Certificat SSL

Bonjour tous le monde ! Dans ce nouvel article, je vous propose d’aborder le sujet sensible qu’est le choix des certificats SSL et des bonnes pratiques à suivre lors d’un déploiement Exchange 2016.

Exchange 2016 communique avec les clients, applications et les autres serveurs sur une variété de protocoles réseau tels que http, SMTP, IMAP et POP. La plupart de ces communications, particulièrement les clients et applications, impliquent une authentification basée sur l’identification par nom d’utilisateur et mot de passe. Lorsque les informations d’identification sont envoyées sur le réseau, elles sont envoyées « en clair », signifiant que ces informations peuvent potentiellement être interceptées et lues par une personne malintentionnée. D’autres informations transmises durant la session peuvent être également sensibles et enclin à être utilisées si l’interception est possible.

Pour sécuriser ces communications Exchange 2016 utilise les certificats SSL pour crypter le trafic réseau entre le serveur, les clients et les applications. Ceci inclus :

  • Outlook se connectant via Outlook Anywhere (RPC-over-HTTP) ou MAPI-over-HTTP
  • Les navigateurs Web se connectant à Outlook sur le Web (OWA)
  • Les appareils mobiles se connectant via ActiveSync pour accéder aux boîtes aux lettres et calendriers.
  • Les applications se connectant aux services Web Exchange (EWS) pour consulter les disponibilités et autres
  • Les clients de messagerie se connectant en POP ou IMAP
  • Le trafic SMTP cryptés en TLS entre les serveurs Exchange et les autres serveurs de messagerie

Lors de la première installation d’Exchange 2016, il génère un certificat SSL auto-signé qui est alors activé pour IIS (les services HTTPS comme OWA, EWS et ActiveSync), SMTP, POP et IMAP. Le certificat auto-signé permet au serveur d’être « sécurisé par défaut » et de commencer à crypter les communications réseau de suite après son démarrage, mais il est seulement censé être utilisé temporairement jusqu’à que vous provisionniez les certificats SSL pour votre environnement.

Lors du déploiement d’Exchange 2016 vous devez planifier de remplacer le certificat auto-signé par un certificat SSL valide pour votre scénario de déploiement. Ceci implique un investissement allant d’une centaine de dollars (ou €) à plusieurs milliers de dollars (ou €) dépendant de votre scénario d’espace de noms d’accès client, le type de certificat que vous achetez, et le type de d’autorité de certification auquel vous vous adressez.

Il fortement recommandé de ne pas conserver le certificat auto-signé ou de désactiver SSL pour les services Exchange.

Certificat SSL – Prérequis

Il y a trois prérequis basiques pour un certificat SSL dans un déploiement Exchange 2016.

  • Noms de serveur/domaine correct – le certificat SSL doit contenir les espaces de noms (aka, URLs, alias, noms de domaines) correspondant au nom auquel les clients tentent de se connecter (par exemple, les utilisateurs tapant « webmail.contoso.com » dans leur navigateur web pour pouvoir accéder à Outlook web app)
  • Période de validité du certificat – chaque certificat SSL a une période de temps fixée durant laquelle il est considéré comme valide. Lorsque le certificat SSL atteint sa date d’expiration il devra être renouvelé pour continuer à fonctionner.
  • Une autorité de certification de confiance – les clients feront uniquement confiance aux certificats qui sont issues d’une autorité de certification de confiance. C’est une des raisons pour laquelle le certificat auto-signé ne correspond généralement pour une utilisation en production, parce que vos clients ne feront pas confiance au certificat publié par votre serveur Exchange. Il existe un large panel d’autorités de certification publiques auprès desquelles vous pouvez acquérir des certificats.

Choisir une autorité de certification est assez simple, et la période de validité sera déterminé par la durée pour laquelle vous achetez le certificat (en général minimum 12 mois). Cela signifie que le point de décision pour la planification de vos certificats SSL se reposera sur le choix de vos espaces de noms.

Espace de noms pour les certificats SSL

L’approche la plus simple pour les espaces de noms Exchange 2016 Server est d’utiliser un seul espace de noms pour tous les services HTTPS.

En plus de l’espace de noms HTTPS, il est courant d’utiliser un espace de noms séparé pour chacun des services SMTP, POP et IMAP, bien qu’il ne soit pas nécessaire de le faire. Il y a également le CNAME de l’Autodiscover à considérer et le domaine racine également.

Par exemple, dans un environnement simple où le nom de domaine utilisé pour les adresses de messagerie est contoso.com, et en prenant en compte toutes les considérations citées précédemment, les espaces de noms pourraient être planifiées comme :

  • Webmail.contoso.com (pour HTTPS, SMTP, POP et IMAP)
  • Autodiscover.contoso.com (pour le CNAME de l’Autodiscover)
  • Contoso.com (pour le domaine racine des recherches autodiscover)

La pratique recommandée est d’inclure uniquement les alias en tant qu’espace de noms sur les certificats SSL et pas le FQDN des serveurs.

Note : Concernant la présence du ou des FQDNs des serveurs dans les certificat SSL, il est clair que cela est supporté mais ce n’est cependant pas une bonne pratique car dans les grands environnements il est important de réduire les coûts et les frais généraux administratifs. De plus, dans les grands environnements les services sont configurés avec des espaces de noms qui résolvent des adresses IP Virtuelles (Load Balancing) et utiliser un nom de serveur dans les URLs peut amener à vous causer des problèmes lors de future migration.

En raison des récents changements apportés aux règles d’émission de certificat, vous pouvez également vous trouver dans l’impossibilité de demander un certificat SSL pour un nom de domaine qui n’est pas routable sur Internet ou que vous ne possédez pas légitimement (par exemple, domain.local).

Quel type de certificat acquérir ?

Les autorités de certification tels que Digicert peuvent vous vendre une variété de types de certificat, et certaines autorités de certification différents noms pour ce qui est sensiblement la même chose.

  • Le certificat SSL standard contient un seul nom et est généralement le moins cher à acquérir, cependant ils ne sont pas adaptés même avec une conception d’espace de noms la plus simple.
  • Le certificat SSL Wildcard vous permet de sécuriser de multiple noms sur un domaine sans avoir à spécifier les noms exacts dans le certificat. Bien que qu’ils soient souvent une option à moindre coût, les certificats Wildcard peuvent poser des problèmes de compatibilité avec certains scénarios d’intégration avec d’autres systèmes, ainsi que de ne pas être adapté aux configurations POP et IMAP sécurisées.
  • Le certificat SAN ou UC (Unified Communications) est le type de certificat recommandé. Le certificat SAN peut contenir de multiple noms. Par exemple, un certificat UC peut inclure jusqu’à 4 noms à un prix normal, avec en option la possibilité d’ajouter jusqu’à un total de 25 noms avec un coût supplémentaire. Bien que le coût d’un certificat SAN/UC soit plus important qu’un certificat Wildcard, vous rencontrerez moins de problème de compatibilité avec le certificat SAN/UC, aussi longtemps que le certificat contienne les bons noms. Si toutefois lors de votre planification d’espace de noms vous faite une erreur ou, vous rencontrez le besoin de modifier l’espace de noms, la plupart des fournisseurs vous permettrons de republier le certificat gratuitement. Pour certain cette opération à un coût J.

La pratique recommandé est de provisionner le moins de certificat SSL possible et ce, pour simplifier l’administration ainsi que de réduire le plus possible les coûts à l’achat. Donc bien qu’il soit possible d’avoir des certificats pour chacun des services (http, SMTP, POP et IMAP), il est recommandé d’utiliser qu’un seul certificat contenant tous les noms à moins que vous ne soyez dans un scénario bien spécifique. De même qu’il est recommandé d’utiliser le même certificat pour tous les serveurs Exchange qui seront configuré avec le même espace de noms.

C’est ainsi que se termine cet article. J’espère que les informations fournies tout au long de ce post pourront vous être utiles lors de vos prochains déploiement d’Exchange 2016 !

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.