Tag Archive: certificat


FAQ Certificat avec Exchange

Hello,
Aujourd’hui, nous allons étudier une partie de la sécurité d’Exchange, les certificats. Beaucoup d’administrateurs de messagerie appréhendent ces questions. Cette appréhension est simplement due selon moi à un manque d’expérience et de confrontation à ces environnements généralement maîtrisés par nos collègues de la sécurité, collègues qui parlent un langage propre à eux d’ailleurs…
Le but ici n’est pas de faire un step by step sur l’installation, le renouvellement ou la suppression de certificat ; mais de répondre aux premières questions que les administrateurs Exchange 2007/2010 se posent quand on parle de certificats.

1. Qu’est-ce qu’un certificat ?

Le certificat est une carte d’identité. Prenons l’exemple de la banque, lorsque l’on accède aux services web d’une banque, on arrive sur une adresse en https://nomdelabanque.com. La banque, pour certifier à ces utilisateurs que le site lui appartient bien, fait appel une société tierce, reconnue par tout le monde, pour valider l’identité du service web.

2. Pourquoi en ai-je besoin pour Exchange ?

En plus de permettre la conformité du service web, le certificat permet de chiffrer la communication entre le service et son client. Dans la partie qui nous intéresse, les certificats seront utilisés pour l’ensemble des services web : Outlook Web Access, Autodiscover, Outlook Anywhere et ActiveSync.

3. Quel type de certificat ai-je besoin ?

La réponse peut se découper en deux parties :
– Un certificat X.509, répondant à la RFC 2459 (http://www.ietf.org/rfc/rfc2459.txt). Ces certificats X.509 sont utilisés d’une infrastructure à clefs publiques. C’est-à-dire que le client qui accède un service web sécurisé par un certificat X.509 va utiliser la clef publique (présente dans le certificat) de ce service web pour chiffrer sa communication avec ce dernier. La communication ne pourra être déchiffrée que par la clef privée qui correspondra à la clef publique qui l’a chiffrée. La clef privée est bien sûr connue uniquement du service web.
– L’administrateur pourra utiliser :
o Un certificat issu d’une autorité de certification (CA) reconnue par l’ensemble du monde. Ces autorités de certification sont souvent payantes (exemple : VeriSign) et sont utilisées dans les cas les plus simples,
o Un certificat issu d’une autorité de certification interne (sur un serveur Windows Server, ou autre bien sûr…)
Nous reviendrons plus en détails sur ces deux solutions plus tard.

4. Pourquoi ai-je une erreur de certificat ?

L’erreur de certificat peut apparaître soit dans Outlook soit dans le navigateur web. Les principales erreurs liées aux certificats sont :
– Incohérence entre le nom du certificat et le nom du service. Par exemple, j’héberge un site sécurisé sur ma machine. Le certificat est prévu pour le nom public du site web qui est webmail.tartanpion.com. A des fins de tests j’entre https://localhost dans mon navigateur. Le nom « localhost » n’étant pas renseigné dans le certificat, j’obtiens l’erreur « Le certificat a été généré pour un autre adresse de site web »,
– La date de validité du certificat a expiré,
– Le certificat a été émis par une autorité de certification non reconnue. Le certificat est émis par une autorité de confiance. Pour valider le certificat, il faut que le client fasse confiance à l’autorité. Donc, deux points :
o Si vous utilisez une autorité de confiance publique, telle que VeriSign, l’erreur n’aura jamais lieu quel que soit le client ou la plateforme utilisée car tous les systèmes font confiance à ces autorités publiques (voir le magasin des certificats des autorités racines de confiance http://technet.microsoft.com/fr-fr/library/cc754431(WS.10).aspx

o Si vous utilisez une autorité interne, il sera nécessaire d’installer le certificat de l’autorité interne en tant qu’autorité racine de confiance. Cette action devra être réalisée sur l’ensemble des postes et plateformes de votre société. Si les postes ne font pas confiance à l’autorité interne, ils recevront l’erreur citée. Les accès réalisés par des postes extérieurs à l’entreprise (poste personnel, cybercafé,…) entraineront toujours une erreur, c’est tout à fait normal puisqu’un poste ne fera naturellement pas confiance à votre autorité interne.

5. Les SANs, Stockage Area network…
Et bien non, cet acronyme signifie Subject Alternative Names. C’est une fonctionnalité des certificats X.509 et des listes de révocation (RFC 3280, http://tools.ietf.org/html/rfc3280). Comme je l’ai dit toute à l’heure, les certificats X.509 sont utilisés par plusieurs services web Exchange. Parallèlement, il est impossible d’avoir plusieurs sites web sécurisés avec plusieurs noms sur une même adresse IP, et généralement les serveurs Exchange n’ont qu’une adresse IP. Donc pour simplifier l’architecture, nous allons utiliser une seule adresse IP avec un seul certificat qui comprendra plusieurs noms (webmail, autodiscover, activesync,…). Les SANs seront donc définis par vos soins dans votre étude préalable en fonction de vos besoins. Les SANs devront aussi contenir les noms NetBIOS et fqdn des serveurs Exchange si cela ne pose de problèmes de sécurité : dans le cas où vos serveurs Exchange sont publiés directement sur Internet, cette option est à proscrire.

6. Un certificat issu d’une CA publique
Le choix d’une CA publique est généralement plus simple :
– Le certificat est reconnu automatiquement par tous les systèmes d’exploitation et par tous les terminaux,
– La gestion de cycle de vie du certificat est limitée au certificat Exchange,
– La gestion de la liste de révocation est réalisée par l’autorité publique.
La plupart de ces autorité sont payantes (VeriSign par exemple) mais d’autres comme GoDaddy sont gratuites.

7. Un certificat issu d’une CA interne
L’installation d’une CA interne apparait au premier abord toujours plus simple : installation relativement aisée sur un Windows Server, peu de coûts associés, flexibilité lors des tests,… Je suis en complet désaccord avec cela. Le choix d’une CA interne doit être arrêté lorsque l’entreprise dispose de compétences sécurité, la gestion d’une autorité de certification est un métier à part entière, ou d’une autorité interne existante.
Toutefois, si vous décidez d’installer une CA pour les besoins précis Exchange, prenez en compte ces considérations :
– Le serveur qui joue le rôle d’autorité de certification ne joue que ce rôle : surtout pas de contrôleurs, base de données,…
– Préférez un système hiérarchique à deux niveaux d’autorités (primaire/secondaire) pour plus de sécurité,
– Faites attention aux dates d’expiration des certificats des autorités racines : si le certificat d’une autorité racine expire, la réinstallation est obligatoire,
– Déployer les certificats racine via stratégie de groupe, la GPO doit être appliquée au niveau du domaine,
– Former vos utilisateurs à outrepasser les erreurs de certificat pour les accès extérieurs.

8. Mais pourquoi le certificat auto-signé n’est pas suffisant ?
Lors de l’installation de tous les rôles Exchange sauf Mailbox, un certificat est installé sur les serveurs : il est délivré au nom NetBIOS de la machine par le même nom NetBIOS de la machine. Le nom fqdn de la machine est renseigné dans les SANs. C’est d’ailleurs pour cette raison qu’il est possible de se connecter avec Outlook et OWA à partir d’une machine du même domaine que le serveur Exchange contacté.
Les limitations du certificat auto signé sont :
– Durée de validité : 1 an pour les versions d’Exchange avant 2007 SP2, 5 an à partir du SP2,
– Impossibilité d’utiliser les services Outlook Anywhere, Active Sync et OWA en dehors du réseau de l’entreprise

9. Un peu de technique, comment afficher les certificats utilisés ?
Pour exchange 2007, Powershell uniquement. La version 2010 permet une gestion par interface graphique en plus de la ligne de commande.
Powershell : Get-ExchangeCertificate.
GUI : cliquer sur le nœud « Server Configuration »

Publicités
Bonjour,

Pour le premier billet technique, je vais aborder la coexistence frontal Exchange 2003/CAS Exchange 2010. Il ne sera pas ici question de définir les pré-requis d’installation des rôles Exchange ni de décrire l’installation mais de spécifier les actions à réaliser pour permettre à vos utilisateurs de conserver leurs liens OWA Exchange 2003 pour Exchange 2010.

L’architecture est la suivante :

1 DC+PKI en 2003 (oui ok c’est pas best practices mais bon maquette…) qui s’appelent « dc2003« ,

1 backend en 2003qui s’appelle « exch2003b« ,

1 frontal 2003 qui s’apppelle « exch2003f« .

Le domaine AD est appelé group.toc. Dans le cadre de l’article, les DNS hébergent deux zones DNS : group.toc et tartanpion.fr. La zone group.toc répertorie les enregistrements des machines membres du domaine AD et la zone tartanpion.fr correspond au nom de la zone publique de l’entreprise factice. Les clients utilisant en interne et en externe l’URL webmail.tartanpion.fr, C’est dans cette dernière zone que l’on va ajouter les alias pour l’OWA. Le fait d’avoir une zone tartanpion.fr déclarée à la fois dans les DNS publics (FAI,…) et dans les DNS privés est apellé split-dns.

Nous avons donc au début de l’article dans la zone tartanpion.fr un alias du nom de webmail qui pointe sur l’enregistrement exch2003f.group.toc.

Ces trois serveurs représentent l’environnement source.

L’environnement cible est représentée par une seule machine DC+Exchange 2010 (multirole) en 2008 R2 (toujours pas best practices)  et qui s’appelle « dc2008R2« .

Pour résumé litéralement l’article, pendant la phase de coexistence, et principalement quand les serveurs CAS 2010 seront en production, tous les clients attaqueront toujours leur OWA par webmail.tartanpion.fr. Ils seront alors redirigés vers les CAS 2010. Ils s’authentifieront alors sur le nouveau formulaire Exchange Server 2010. Si leur boîte aux lettres a déjà été migrée, l’utilisateur de connecte directement. Au contraire, si la boîte n’est pas migrée, l’utilisateur sera redirigé sur legacy.tartanpion.fr qui correspondra au frontal 2003.

1ère Etape : Configuration du certificat sur le CAS 2010

Exchange 2007 avait déjà amené une couche concernant les certificats, la nouvelle version est sur la même lancée ; avec ceci que maintenant nous disposons d’une interface graphique. L’installation sera réalisée en interface graphique pour permettre à un maximum de personnes d’aborder le sujet sans appréhension.

La nouveauté 2010 est de pouvoir gérer les certificats Exchange à partir de l’interface graphique. NB : les certificats visibles dans le screenshot correspondent : 1 au certificat autosigné d’Exchange disponible par défaut dans tous les environnements et 2 au certificat machine déployée par GPO pour d’autres besoins… L’ignorance est de mise !

Nous allons donc nous permette un bon clic droit « New Exchange Certificate » dans le panneau « Actions » de droite.

Le nom indiqué est un nom fqdn. Ce n'est absolument nécessaire...

Sur la partie wildcard, cliquer sur Next

L’étape importante est la configuration Exchange. En fonction des besoins, vous devrez cocher OWA, ActiveSync, OAnywhere,… Dans le cadre du billet, les options OWA et Legacy Exchange Server seront modifiées. Pour la partie OWA, renseigner vos noms fqdn interne et externe (pour l’article : webmail.tartanpion.fr) et dans la partie Legacy, noter la future adresse du serveur frontal 2003 (pour l’article : legacy.tartanpion.fr).

Dans la fenetre des SANs, valider que votre enregistrement webmail (ici webmail.tartanpion.fr) est configuré comme nom commun. Renseigner ensuite les champs nécessaires au certificat (correspondant à votre situation) et générer le fichier de demande .req.

Le fichier .req peut selon les situations être envoyés à une autorité de certification publique payante (comme VeriSign), dans ce cas le certificat devra être de type « Communications unifiées » ou à une autorité Windows interne, le modèle utilisé devra alors être « Serveur Web » 

Une fois le certificat en poche, il faut compléter la requêta via la console Exchange et un clic droit « Complete Pending Request » sur le certificat avec le nom commun qui correspond à votre webmail (ici, webmail.tartanpion.fr)

Via l'assistant, configurer le certificat récupéré précédemment

Dernière étape, configurer les services Exchange qui utiliseront le certificat installé. Toujours par un client sur le serveur dans l’interface graphique « Assign Exchange Certificate ».

Seule la partie IIS est nécessaire pour OWA

Bleu c’est définitivement mieux que rouge

Et voilà, le certificat est valide et installé.

Deux tests rapides pourront être réalisés via naviguateur

Le certificat présenté est bien délivré à webmail.tartanpion.fr

Les deux noms sont bien présents dans le certificat

2ème étape : configuration Exchange

Deux commandes sont nécessaires pour configuration chaque serveur CAS :

1. set-owavirtualdirectory nom_de_serveur\OWA* – ExternalURL https://webmail.tartanpion.fr/OWA -Exchange 2003URL https://legacy.tartanpion.fr/Exchange

Après avoir modifié l’URL OWA, le système prévient de ne pas oublier l’Exchange Control Panel

2. Set-ecpvirtualdirectory nom_de_serveur\ECP* -ExternalURL https://webmail.tartanpion.fr/ECP

3ème étape : Export du certificat Exchange 2010 pour Exchange 2003

A partir de maintenant, si un utilisateur non migré arrive sur l’OWA de l’exchange 2010 et s’authentifie ; le serveur Exchange 2010 le redirigera vers l’adresse legacy.tartanpion.fr. Il est donc nécessaire de modifier le certificat des OWA 2003 pour ne pas avoir d’erreur.

A partir d’un CAS, lancer une MMC « Certificats » et exporter le certificat webmail.

L'export de la clef privée est obligatoireVérifier que le certificat est exporté au format .pfx. Si votre certificat est issue d'une autorité qui est elle approuvé par une autre autorité, penser à cocher la case "Include all certificates in the certification path if possible"

Le certificat .pfx devra être copié sur chaque serveur CAS. La réimportation du nouveau certificat se faire via IIS

Pour plus d’assurance, le certificat actuel devra être supprimé et non remplacé.

La configuration du nouveau certificat se fera via l’import du fichier .ofx et de la saisie du mot de passe

Et après un reboot d’IIS, le certificat est correct !

3ème étape : Configuration DNS

Deux alias seront nécessaires : webmail.tartanpion.fr qui pointaient sur les serveurs Exchange 2003 pointera maintenant sur les serveurs Exchange 2010 (voire même un CAS array…) ; legacy.tartanpion.fr devra pointer sur les frontaux 2003.

4ème étape : LES TESTS !!!

Nous avons deux possibilités :

1. Les serveurs frontaux acceptent l’authentification basée sur formulaires, vous etes alors le roi du monde. Lorsqu’un utilisateur s’authentifiera sur webmail.tartanpion.fr (formulaire Exchange 2010 depuis l’étape 3), il sera redirigé avec sso vers l’OWA et sa boîte 2003

2. si non, la redirection devra être manuelle. Il faudra passer sur chaque CAS 2010 la commande « set-OwaVirtualDirectory -LegacyRedirectType manual« . Ensuite l’utilisera devra s’authentifier sur le formulaire 2010 et le 2003…

Voilà, ce premier billet est fini ! Désolé pour la mise en page mais je prends en main l’outil…

Vos commentaires, remarques (et insultes) seront les bienvenus. Et je tiens à remercier Tony aka Leboss aussi 😮