Choisir le bon type de certificat SSL Thawte pour Microsoft

Transcription

Choisir le bon type de certificat SSL Thawte pour Microsoft
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 messagerie1. 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 mobile2. 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.

Documents pareils

Certificat wildcard SSL

Certificat wildcard SSL support.thawte.com et mail.thawte.com). Comparée à l’acquisition et au déploiement d’un certificat différent pour chacun de vos sous-domaines, l’utilisation de certificats Thawte Wildcard offre une...

Plus en détail