Sécurisation de Microsoft Exchange 2011 avec les certificats SSL Thawte
SSL fort = communications sécurisées C'est le moment de passer à Microsoft Exchange Server 2010 et ceci pour plusieurs raisons, notamment pour les nombreuses améliorations en matière d'administration et de sécurité. Néanmoins, à l'instar de Microsoft Exchange Server 2007, Exchange 2010 requiert des certificats SSL pour sécuriser toutes les connexions du serveur de messagerie. Ce guide de Thawte est destiné à clarifier les étapes de mise en œuvre du SSL pour Exchange 2010, afin de faciliter l'obtention du certificat SSL requis pour assurer un déploiement d'exchange efficace et sécurisé. Il vous sera également utile pour exploiter de puissantes fonctionnalités, telles que les Subject Alternative Names (SAN). Qu'est-ce qu'un certificat SSL? Un certificat SSL est un bout de code qui assure la sécurité de vos communications en ligne. Lorsqu'un navigateur Internet contacte votre site Web ou serveur d'application sécurisé, il utilise le certificat SSL pour activer une connexion chiffrée. C'est un peu comme si vous apposiez un sceau sur une lettre avant de la placer dans une enveloppe et de l'envoyer par courrier. Les certificats SSL inspirent également confiance car chacun d'entre eux contient des informations d'identification. Lorsque vous demandez un certificat SSL, un tiers (tel que Thawte) vérifie les informations de votre entreprise et émet un certificat unique à votre intention contenant ces informations. Il s'agit du processus d'authentification. Sélection d'un type de certificat SSL pour Exchange 2010 Vous pouvez utiliser trois types de certificats SSL différents pour protéger votre infrastructure Exchange : certificats auto-signés créés par vos propres soins, certificats d'infrastructure PKI Windows et certificats émis par des autorités de certification indépendantes (également appelés "certificats publics"). Microsoft recommande d'utiliser un certificat SSL émis par une autorité de certification indépendante de confiance avant de procéder à la mise en production d'un nouveau serveur de messagerie 1. En utilisant un certificat émis par une autorité de certification bien établie, vous évitez d'avoir à gérer l'installation de votre propre certificat racine sur chaque client qui accède à votre serveur Exchange. Le support technique vous en sera reconnaissant car des requêtes de configuration seront envoyées à chaque tentative de connexion d'un nouveau client Web ou mobile 2. Par ailleurs, notez que le protocole Outlook Anywhere ne fonctionne pas avec un certificat SSL auto-signé. Dénomination des serveurs Exchange Avant d'acheter et d'installer des certificats SSL, vous devez identifier le nom de domaine complet (ou FQDN pour Fully Qualified Domain Name, également appelé "URL" ou "nom commun") de votre serveur et ajouter ce nom à la liste des serveurs approuvés dans Active Directory. Le FQDN doit se présenter comme suit : mail.votreserveur.com Vous aurez besoin de plusieurs FQDN pour le serveur. Celui-ci sera très certainement responsable de plusieurs services et vous devrez identifier chaque nom susceptible d'être utilisé par un autre serveur ou client pointant vers votre serveur Exchange. S'il semble préférable de gérer les noms communs Exchange au format FQDN, certaines restrictions doivent être prises en compte. Les noms communs peuvent compter jusqu'à 64 caractères. Si votre schéma de dénomination FQDN s'avère long, votre FQDN complet ne tiendra pas dans la norme du nom commun. Les noms communs prennent en charge le format Unicode, alors qu'un nom FQDN est limité à un sous-ensemble de caractères ASCII. Néanmoins, utiliser le FQDN en tant que nom commun ne peut que contribuer à simplifier votre configuration. 1. Microsoft TechNet, Understanding Digital Certificates and SSL : http://technet.microsoft.com/en-us/library/dd351044.aspx 2. Patricio Anderson, Managing Certificates in Exchange Server 2010 : http://www.msexchange.org/articles_tutorials/exchange-server-2010/management-administration/managingcertificates-exchange-server-2010-part1.html [7 avril 2001] 1
Certaines situations peuvent vous amener à utiliser le FQDN en tant que nom commun, par exemple lors de la sécurisation d'un serveur de transport Edge qui exécute le protocole SMTP sécurisé (SMTPS) sur Internet. Dans ce cas, vous devez utiliser le FQDN tel qu'il est indiqué dans l'enregistrement "A" du serveur sur le DNS Internet public. S'il n'est pas possible ou souhaitable d'utiliser le FQDN, la plupart des administrateurs utilisent le nom de domaine court du FQDN comme nom commun. Ci-dessous un groupe type de noms communs pouvant être associés à un serveur Exchange unique : mail.votreserveur.com owa.votreserveur.com autodiscover.votreserveur.com outlook.votreserveur.com Vous devez sécuriser et authentifier chacun de vos noms communs avec SSL car tout périphérique pointant vers votre serveur devra utiliser exactement les mêmes noms. De nombreux professionnels de l'informatique ont rencontré des problèmes de fonctionnement dus à une mauvaise compréhension du nom commun du serveur dans le déploiement d'exchange. La création d'un schéma de dénomination fiable pour l'environnement Exchange vous permettra d'éviter nombre de problèmes graves. Utilisation simplifiée des Subject Alternative Names S'il est vrai que chacun de vos noms communs doit être authentifié via SSL, acheter et installer un certificat SSL distinct pour chacun des noms communs s'avérerait aussi fastidieux que coûteux. Heureusement, il existe une méthode bien plus simple. Si vous devez sécuriser plusieurs noms communs pour un serveur unique, comme l'exige un serveur Exchange, la solution consiste à obtenir un certificat avec plusieurs SAN (Subject Alternative Names). L'extension de champ SAN d'un certificat SSL fait partie de la norme des certificats SSL depuis plus de dix ans. Ce certificat avec prise en charge du SAN fonctionne pratiquement comme un certificat SSL classique. Il offre le même niveau de chiffrement et d'authentification ; en revanche, il protège plusieurs noms communs à l'aide d'un même certificat SSL. Extrêmement flexible, l'extension de champ SAN fonctionne avec la plupart des navigateurs et appareils mobiles. L'extension de champ SAN permet de protéger plusieurs domaines, adresses IP, noms de serveurs et autres à l'aide d'un seul certificat. C'est la solution idéale pour assurer la sécurité de votre serveur Exchange. Pratiques d'excellence pour le SAN Utilisez le "nom principal du certificat" configuré pour votre connexion Outlook Anywhere dans le profil Outlook, comme nom d'objet du certificat SSL. Intégrez dans le certificat le nom de domaine Internet complet (FQDN) du serveur en tant que nom commun. Notez également que le service Autodiscover (si vous l'utilisez) doit être indiqué en tant que SAN, sous la forme autodiscover.votreserveur.com. Tous les noms communs des différents services utilisés avec le déploiement d'exchange doivent être indiqués dans votre SAN. Les principaux services utilisés sont Outlook Web App (OWA), ActiveSync et Outlook Anywhere. Si vous avez déployé plusieurs CAS (Client Access Servers ou serveurs d'accès aux clients), vous devez également intégrer tous les FQDN correspondants dans votre liste de SAN. Certificats Wildcard Les certificats Wildcard sont différents des certificats SAN. Ils peuvent protéger un nombre illimité de sous-domaines. Par exemple, un certificat Wildcard pour *.votredomaine.com sécurise les sous-domaines tels que info.votredomaine.com et boutique.votredomaine.com Cependant, les certificats Wildcard sont limités dans le sens où ils doivent partager le même domaine et le même nombre de niveaux. Par ailleurs, il est impossible de sécuriser le service Autodiscover d'exchange à l'aide d'un certificat SSL Wildcard. 2
Utilisation du nouvel assistant de création de certificat d'exchange Server 2010 L'assistant de création de certificat Exchange facilite considérablement la configuration des noms de domaine pour Exchange Server 2010. Sa nouvelle interface utilisateur remplace Exchange PowerShell. L'option de configuration d'exchange définit une configuration de serveur standard à utiliser pour commander le certificat SSL. Lorsque vous l'utilisez, vérifiez les options de configuration par défaut par rapport à votre déploiement réel. Vous éviterez ainsi de commander les mauvais SAN pour le certificat SSL parce que votre dénomination n'est pas la même que la configuration Exchange par défaut. Achat du certificat SSL Une fois que vous avez mappé tous les noms de SAN, vous pouvez passer à l'achat du certificat SSL. Acheter un certificat SAN ne présente aucune difficulté, mais vous devez au préalable déterminer le nombre de SAN requis pour le certificat. Certaines autorités de certification vous permettent de modifier les SAN existants si vous devez changer un nom. Dans ce cas, vous devrez réémettre le certificat et le réinstaller pour appliquer les modifications au niveau du serveur. Tous les fournisseurs SSL ne proposent pas nécessairement la réémission gratuite illimitée de leurs certificats. Il est donc important de choisir une marque qui offre cette possibilité, comme Thawte. Sélectionnez un fournisseur SSL fiable et crédible, avec des racines omniprésentes pour la prise en charge immédiate de nombreux navigateurs et serveurs. Inutile pour vous de perdre un temps précieux à vérifier que les racines SSL de votre autorité de certification se trouvent bien aux endroits attendus. Si vous disposez de plusieurs certificats, vous pouvez envisager d'acheter un certificat SSL pour entreprise. En règle générale, ce type de certificat va de pair avec des consoles d'administration performantes, permettant d'effectuer un suivi centralisé de tous les certificats, d'éviter les pannes liées à des expirations inattendues, voire de créer des rapports pertinents pour vous aider à planifier vos besoins futurs en matière de certificats SSL. Options d'achat de certificats SSL SAN Un certificat SSL SAN, également appelé "Unified Communications Certificate" ("certificat UC" ou tout simplement "UCC"), n'est généralement pas émis sous forme de produit spécialisé distinct. Idéalement, vous devez pouvoir sélectionner le certificat SSL avec le niveau d'authentification que vous recherchez, puis indiquer les noms supplémentaires à sécuriser à l'aide du certificat. Certaines autorités de certification proposent un seul type de certificat UC, une restriction qui n'existe pas avec Thawte. Vous pouvez ajouter des SAN aux certificats Thawte SGC SuperCerts, aux certificats SSL pour serveur Web Thawte et aux certificats SSL avec EV pour serveur Web Thawte. Vous aurez à régler le prix du certificat d'origine, plus les frais liés à l'activation des SAN pour sécuriser d'autres noms de domaine. Génération d'une requête de signature de certificat via l'assistant de création de certificat Exchange Pour enregistrer le certificat SSL, vous devez générer une requête de signature de certificat (RSC). Dans cette optique, Exchange 2010 propose un assistant de création de certificat qui simplifie le processus. Pour générer votre propre RSC, procédez comme suit : 1. Ouvrez la console de gestion Exchange via Démarrer > Programmes > Microsoft Exchange 2010 > Console de gestion Exchange. Sélectionnez "Gérer les bases de données" comme indiqué dans la capture d'écran en page suivante. 3
2. Sélectionnez "Configuration du serveur" dans le menu de gauche, puis "Nouveau certificat Exchange" dans le menu des actions sur la droite. Lorsque vous êtes invité à indiquer un nom convivial, entrez un nom qui vous permettra d'identifier facilement le certificat. Uniquement utilisé dans le cadre de l'identification, ce nom ne fait pas partie de la RSC. 3. Sous Etendue de domaine, vous pouvez cocher la case si vous générez la RSC pour un certificat Wildcard. Si tel n'est pas le cas, passez à l'étape suivante. 4. Dans le menu Configuration Exchange, sélectionnez les services à sécuriser et entrez les noms utilisés pour vous connecter à ces services à l'invite du système. 5. Dans l'écran suivant, vous pouvez passer en revue la liste des noms proposés par Exchange 2010 pour intégration dans votre requête de signature de certificat. Le champ "Organisation" doit contenir la dénomination sociale complète (officielle) de votre entreprise, et le champ "Unité d'organisation" doit indiquer votre service dans l'organisation responsable de SSL. 4
6. Cliquez sur Parcourir pour enregistrer la RSC au format.req, puis sélectionnez Enregistrer. Cliquez ensuite sur Suivant, Nouveau et Terminer. Vous pouvez maintenant ouvrir la RSC à l'aide d'un éditeur de texte tel que le Bloc-notes. Copiez toutes les informations, depuis le premier tiret (-) de la ligne DEBUT jusqu'au dernier tiret de la ligne FIN. Collez-les dans le formulaire de commande en ligne. REMARQUE : Exchange 2010 utilise une clé RSA de 1 024 bits par défaut, mais Thawte recommande vivement d'utiliser une clé de 2 048 bits. Si vous créez une RSC pour un certificat Extended Validation ou un certificat avec une période de validité ultérieure au 31 décembre 2013, vous devez sélectionner une clé de 2 048 bits. Installation du certificat SSL Thawte Si vous avez acheté un certificat SSL de Thawte, vous recevez un message électronique contenant le certificat SSL. Le message se présente comme suit, avec des données codées entre l'en-tête et le pied de page. Il s'agit du certificat SSL. -----DEBUT DU CERTIFICAT----- [données codées] -----FIN DU CERTIFICAT----- A l'aide du Bloc-notes ou d'un autre éditeur de texte, créez un fichier avec le contenu du certificat du message électronique. Veillez à ce que les mentions DEBUT DU CERTIFICAT (BEGIN CERTIFICATE) et FIN DU CERTIFICAT (END CERTIFICATE) soient entourées de cinq (5) tirets, et qu'aucun espace, saut de ligne ou caractère supplémentaire ne soit ajouté par inadvertance. Enregistrez le fichier avec l'extension.txt ou.p7b. Puis, pour installer le certificat SSL Thawte, procédez comme suit : 1. Lancez la console de gestion Exchange : Démarrer > Programmes > Microsoft Exchange 2010 > Console de gestion Exchange. 2. Sélectionnez "Gérer les bases de données", puis "Configuration du serveur". Sélectionnez le certificat dans le menu central (où il est affiché sous son nom convivial), puis sélectionnez "Effectuer la demande en attente" dans le menu "Actions". 3. Recherchez le fichier du certificat, puis sélectionnez Ouvrir > Terminé. Remarque : Il peut arriver qu'exchange 2010 affiche le message d'erreur "Les données sources sont endommagées ou leur codage Base64 est incorrect". En règle générale, vous pouvez ignorer cette erreur ; le plus souvent, le certificat s'installe tout de même correctement. 4. Appuyez sur F5 pour rafraîchir le certificat et vérifiez que la valeur "Faux" est indiquée sous "Auto-signé". Si la valeur "Vrai" reste affichée, il se peut que vous ayez sélectionné le mauvais certificat ou que la requête ait été générée sur un autre serveur. Pour résoudre ce problème, créez une nouvelle RSC sur le serveur Exchange et demandez la réémission du certificat par votre autorité de certification. 5. Pour activer le certificat, revenez à la console de gestion Exchange et cliquez sur le lien permettant d'"affecter des services au certificat". Sélectionnez le serveur dans la liste, puis cliquez sur Suivant. 6. Sélectionnez les services pour lesquels le certificat doit être activé, puis cliquez sur Suivant > Affecter > Terminer. Félicitations! Le certificat SSL Thawte doit maintenant être installé et activé en vue de son utilisation dans votre environnement serveur Microsoft Exchange 2010. 5
Adoptez SSL dès maintenant Certificats SSL Thawte pour Exchange 2010 Avec Thawte comme fournisseur de confiance en ligne, les clients se sentiront en sécurité lors de leurs échanges commerciaux avec vous sur Internet. Grâce à un support d'experts en plusieurs langues, des pratiques d'authentification fiables et une gestion en ligne aisée, Thawte constitue le meilleur rapport qualité/prix concernant les certificats SSL et Code Signing. Adaptés à Exchange 2010, les certificats Thawte SGC SuperCerts, SSL pour serveur Web Thawte et SSL avec EV pour serveur Web Thawte peuvent être activés pour les SAN. Certificats SAN (Subject Alternative Name) Thawte Les certificats SAN Thawte sont des outils puissants qui permettent de sécuriser plusieurs noms de domaine de façon efficace et économique. Egalement appelés Unified Communications Certificates (UCC), ces certificats sont idéaux pour Microsoft Exchange 2010 et Microsoft Communications Server. Pour acheter un certificat SAN, il vous suffit d'acheter un certificat SSL pour serveur Web, un certificat SSL avec Extended Validation pour serveur Web ou un certificat SGC SuperCert, et d'ajouter des SAN lors du processus d'inscription. Contrairement à la plupart des autorités de certification, Thawte ne vous limite pas à une seule option UCC. Vous pouvez obtenir un certificat SAN avec chiffrement SGC (Server Gated Cryptography), aussi bien qu'un certificat SAN avec Extended Validation ou un certificat SAN avec validation de l'organisation. Thawte propose une solution de création de certificat SAN flexible, qui s'adapte en fonction de vos besoins. Thawte SGC Supercerts Les certificats Thawte SGC Supercerts assurent la sécurité des transactions en ligne en permettant à chaque internaute de profiter du niveau de chiffrement SSL le plus fort possible. La plupart des certificats SSL autorisent un chiffrement fort (128 bits ou supérieur), cependant, certains anciens navigateurs et systèmes d'exploitation ne peuvent pas atteindre un chiffrement 128 bits à moins d'utiliser un certificat SSL avec technologie SGC. Les certificats SGC SuperCerts incluent SGC, l'authentification intégrale de l'organisation, le sceau Thawte Trusted Site Seal, les réémissions gratuites et une garantie de remboursement de 30 jours. Certificats SSL pour serveur Web Thawte Les certificats SSL pour serveur Web Thawte sécurisent les informations confidentielles échangées en ligne et confirment l'identité de votre site aux employés, partenaires commerciaux et autres utilisateurs. Quand les utilisateurs cliquent sur le sceau Thawte Trusted Site Seal ou visionnent les détails du certificat, le nom de votre organisation apparaît et montre que Thawte, une autorité de certification approuvée, a vérifié l'identité de votre site. Les certificats SSL pour serveur Web incluent l'authentification intégrale de l'organisation, le sceau Thawte Trusted Site Seal, les réémissions gratuites et une garantie de remboursement de 30 jours. Certificats SSL avec Extended Validation (EV) pour serveur Web Thawte Les certificats SSL pour serveur Web avec Extended Validation (EV) de Thawte activent l'indicateur de sécurité le plus visible : la barre d'adresse verte dans les navigateurs haute sécurité garantit aux utilisateurs que votre site est sécurisé et que votre identité a été authentifiée selon les normes les plus rigoureuses de l'industrie. Lorsque les clients voient la barre d'adresse verte et le sceau Thawte Trusted Site Seal, ils ont confiance et effectuent leur transaction. A titre de rappel, les certificats Extended Validation peuvent uniquement être émis pour les FQDN et non pour les noms internes. Les certificats SSL avec EV pour serveur Web comprennent le sceau Thawte Trusted Site Seal, les réémissions gratuites et une garantie de remboursement de 30 jours. 6 2011 Thawte, Inc. Tous droits réservés. Thawte, le logo Thawte et les autres marques commerciales, marques de services et logos sont des marques commerciales déposées ou non de Thawte, Inc. et de ses filiales aux Etats-Unis et dans d autres pays. Toutes les autres marques commerciales sont des marques de leurs propriétaires respectifs.