BYOD - Montage d'une plateforme de démo dans Azure - 2ème partie - Détails sur le certificat SSL

Cet article fait partie d'une série :

1. BYOD - Montage d'une plateforme de démo dans Azure - 1ère partie - préparation du réseau, installation du DC et préparation des autres VM
2. BYOD - Montage d'une plateforme de démo dans Azure - 2ème partie - Détails sur le certificat SSL (cet article)
3. BYOD - Montage d'une plateforme de démo dans Azure - 3ème partie - Workplace Join
4. BYOD - Montage d'une plateforme de démo dans Azure - 4ème partie - Work Folders (à venir)
5. BYOD - Montage d'une plateforme de démo dans Azure - 5ème partie - Windows Intune : Dirsync, SSO (à venir)

Dans l'article précédent je vous présentais la mise en place dans Windows Azure de l'infrastructure nécessaire à la démonstration de scénarios de type BYOD. Dans cette première partie nous avons installé le contrôleur de domaine et les machines virtuelles qui accueilleront les différents services nécessaires. Nous terminions sur l'acquisition d'un certificat SSL pour plusieurs noms DNS, nécessaires pour l'accès aux services ADFS, Workplace Join et Work Folders.

Avant d'entrer dans le vif du sujet, voici quelques caractéristiques du certificat que j'ai acquis auprès de Gandi.net (https://www.gandi.net/ssl), chez qui j'ai commandé un certificat standard multi-domaines (https://www.gandi.net/ssl/standard#multi) :

 

Comme on le voit, les plusieurs noms de domaines se trouvent dans l'attribut Subject Alternate Name (SAN) du certificat. Bien sûr, il y existe nombre de fournisseurs de certificats facilement accessibles sur Internet, et mon idée n'est pas d'en priviligier un, mais d'illustrer mon propos d'un cas réel.

Nous allons détailler dans cette deuxième partie la méthode à utiliser pour faire cette acquisition auprès d'une autorité de certification. Quelle que soit celle-ci, la méthode sera équivalente, et peut se résumer à ces quelques étapes :

1. Vérifier auprès du fournisseur la procédure de validation.
2. Sur une machine Windows Server 2012 R2, installer IIS et créer une requête de certificat selon les caractéristiques désirées.
3. Envoyer la requête de certificat à l'autorité de certification.
4. Attendre le temps nécessaire, qui peut varier sensiblement selon l'autorité de certification choisie. Pendant ce temps, conserver la machine utilisée pour la requête en l'état.
5. Une fois le certificat reçu de l'autorité de certification, entrer ce certificat dans la console IIS.
6. Sur la même machine, depuis la console MMC des certificats, exporter le certificat reçu avec sa clé privée (fichier .pfx avec mot de passe).
7. Importer le certificat sur les machines qui en ont besoin.

Je vous conseille également un petit tour sur la documentation de Gandi.net : https://wiki.gandi.net/fr/ssl.

Voyons maintenant comment procéder dans le détail.

Procédure de validation des noms de domaines

Avant d'aller plus loin, il est nécessaire de vérifier auprès du fournisseur de certificats choisi la procédure de validation des noms de domaines demandés. En effet, le fournisseur doit s'assurer que vous êtes propriétaire des noms en question.

Parmi ces méthodes de validation, il peut vous être demandé de :

• créer une adresse email de contact dans chaque domaine afin de recevoir et valider un message de vérification,
• modifier la zone DNS de chaque domaine pour ajouter des enregistrements de contrôle,
• ou récupérer un fichier à déposer à la racine du site web correspondant à chaque domaine.

Dans mon cas, mon fournisseur de certificats étant également mon fournisseur de noms de domaines, la méthode DNS a été automatiquement utilisée.

Préparation de la requête de certificat

Sur une machine Windows Server 2012 R2 indépendante de la plateforme, ou sur le serveur web1 de la plateforme (voir article précédent), installer le serveur web IIS avec la commande PowerShell :

Install-WindowsFeature Web-Server -IncludeManagementTools

Ouvrir la console d'IIS (InetMgr.exe).

Dans la partie gauche, cliquer sur le nom du serveur, puis, au centre de la console, double-cliquer sur Server Certificates.

Dans la partie droite (Actions), cliquer sur Create Certificate Request.

Remplir tous les champs demandés, en choisissant un nom DNS comme Common Name. Le nom www.<domaine> me semble approprié, il servira pour le serveur web. Cliquer sur <Next>.

Choisir l'option RSA (Microsoft RSA Schannel Cryptographic Provider) et la taille de clé 2048 (en fait, celle recommandée par le fournisseur).

<Next>.

Il ne reste plus qu'à spécifier un fichier pour stocker la demande de certificat et cliquer sur <Finish>.

Le contenu de ce fichier ressemble à ceci :

Lors de la création de la requête, le système a généré une paire de clés. Il a conservé la clé privée dans le magasin local de la machine, et la requête de certificat contient la clé publique et les divers attributs que nous avons renseignés. Il faut envoyer cette requête à l'autorité de certification de façon à ce qu'elle la signe pour en faire un certificat.

Envoi de la requête de certificat

Il s'agit ensuite de commander le certificat multi-domaines chez le fournisseur. Chez Gandi par exemple, une fois choisi le type de certificat standard multi-domaines pour 5 noms, voici ce qui est demandé :

Tout d'abord, il est demandé de copier le contenu de la requête de certificat que l'on a créée précédemment. On remarque dans l'image ci-dessus que le domaine principal (CN = www.<domaine>) est automatiquement affiché car il est présent dans la requête.

Il faut ensuite fournir tous les noms DNS supplémentaires (en plus du www) désirés. Pour ma maquette, j'ai besoin de ceux-ci :

• adfs.<domaine> - pour que le serveur ADFS soit joignable par Internet
• enterpriseregistration.<domaine> - pour que le service d'enregistrement de machines, utilisé par la fonctionnalité Workplace Join, soit joignable
• workfolders.<domaine> - pour le service de Work Folders (Dossiers de travail)

Spécifier également le logiciel utilisé (Microsoft IIS...)

Bien évidemment, rien ne vous empêche de demander plutôt un certificat de type wildcard pour *.<domaine>, ou un certificat multi-domaines avec plus de noms (par exemple, puisque j'ai pris un certificat pour 5 noms, j'ai ajouté remote.<domaine> pour prévoir un éventuel service RDS sur la plateforme de démo).

Une fois la demande validée (et facturée...) chez le fournisseur, commence la phase de validation, déjà abordée précédemment.

Après validation, le fournisseur vous prévient que le certificat est disponible, et vous le récupérez sur son site sous la forme d'un fichier (.crt ou .cer...)

Enregistrement du certificat sur la machine émettrice de la requête

Il s'agit maintenant d'enregistrer ce certificat sur la machine avec IIS, celle-là même qui a servi à créer la demande initiale :

Dans la console IIS, cliquer sur le nom du serveur, puis, au centre de la console, double-cliquer sur Server Certificates.

Dans la partie droite (Actions), cliquer sur Complete Certificate Request.

Spécifier le certificat reçu du fournisseur, et le magasin "Personnel", pus cliquer sur <OK>.

Export et conservation du certificat

Une fois que l'on a récupéré le certificat, il s'agit de ne pas le perdre... Pour ce faire, il suffit de l'exporter, avec sa clé privée, dans un fichier .pfx protégé par un mot de passe.

Sur la machine contenant le certificat, lancer mmc.exe, puis ajouter (Ctrl+M) le snap-in Certificates pour le compte de l'ordinateur local.

Dans Certificates (Local Computer) - Personal - Certificates, cliquer à droite sur le certificat et choisir All Tasks - Export.

Dans l'assistant Certificate Export Wizard, cliquer sur <Next>.

Choisir l'option d'exporter la clé privée.

Décocher la case Include all certificates...

Dans cet écran il est très important de choisir l'option Password, et pas l'option Group or user names, même si celle-ci est "recommandée". En effet, elle vous limiterait à un domaine, le domaine de démo. L'option mot de passe permet de ne pas restreindre l'utilisation du certificat que vous avez acheté. Choisissez donc un mot de passe dont vous vous souviendrez aisément.

Il ne reste donc plus qu'à choisir un emplacement et un nom pour le fichier .pfx à créer.

Après le dernier écran de récapitulatif, cliquer sur <Finish> pour générer le fichier .pfx contenant le certificat et sa clé privée.

ATTENTION ! Le fournisseur qui vous a vendu le certificat n'a aucun moyen de vous fournir la clé privée si vous l'égarez. Conservez donc en lieu sûr ce fichier .pfx, duppliquez-le, sauvegardez-le, mais surtout ne le perdez pas, et n'oubliez pas son mot de passe ; il vaut le prix que vous avez payé pour le certificat.

Import du certificat sur une nouvelle machine

Sur les machines qui ont besoin de ce certificat, il faut l'importer dans le magasin de l'ordinateur. Pour ce faire :

Lancer mmc.exe, puis ajouter (Ctrl+M) le snap-in Certificates pour le compte de l'ordinateur local.

Dans Certificates (Local Computer) - Personal, cliquer à droite sur Certificates et choisir All Tasks - Import.

Choisir le fichier .pfx.

Il est maintenant nécessaire d'entrer le mot de passe du .pfx et éventuellement décider que, sur cette machine, la clé privée sera aussi exportable. Ce n'est pas une obligation, surtout si le .pfx est correctement sauvegardé.

Il ne reste plus qu'à confirmer que le certificat doit aller dans le store Personal  de l'ordinateur.

Une fois cet assistant terminé, on peut vérifier que le certificat se trouve bien dans le bon store, dans Certificates (Local Computer) - Personal - Certificates.

Cette manipulation est à répéter sur toutes les machines qui ont besoin du certificat. Si l'on suit la construction de la démo initiée dans le 1er article, il faut importer le certificat sur adfs, file, proxy et web1.

Dans le prochain article, nous nous entrerons dans le vif du sujet avec la configuration du Workplace Join.

Comments

• Anonymous
  July 02, 2014
  Cet article fait partie d'une série : BYOD - Montage d'une plateforme de démo dans Azure - 1ère
• Anonymous
  July 02, 2014
  Présentation [mise à jour importante le 13/12/2013 - voir ci-dessous dans la section Planification ]